The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В ядре Linux 3.13 ожидается появление нового пакетного фильт..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от opennews (??) on 20-Окт-13, 00:12 
В экспериментальную ветку 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.dev/opennews/art.shtml?num=38209

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –9 +/
Сообщение от Аноним email(??) on 20-Окт-13, 00:12 
А я ожидаю, что в 3.13-ом ядре будет из коробки работать подсветка в моём ноутбуке.
Оформил багу на ихней багзилле. Отметил, что с параметром acpi=off регулировка работает (в т.ч. числе горячими клавишами).
Жду.
Завидую тем, которые на багзилле получали фикс на следующий же день.
https://bugzilla.kernel.org/show_bug.cgi?id=62941
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +15 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:13 
Попробуй добавить параметр acpi_osi="!Windows 2012"
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

95. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +11 +/
Сообщение от Аноним (??) on 20-Окт-13, 11:10 
Это не шутка!
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

100. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +7 +/
Сообщение от Аноним (??) on 20-Окт-13, 12:14 
Ох, я столько уже мучался с этим, что и забыл, что в первый раз это может выглядеть как глупая шутка.

Суть в том, что ядро при загрузке вызывает (не знаю, как метод называется, пусть будет) метод _OSI из таблиц ACPI сообщая, что оно понимает все версии Windows и Linux. А тот параметр говорит ядру не сообщать firmware, что оно "совместимо" с Windows 8. В Windows 8 драйверы сами управляют подсветкой и код из таблиц ACPI не вызывается. Производители его не тестируют и поэтому код в ветках поддержки Windows 8 часто бажный. А вот Linux честно его вызывает, что у меня на системе приводит к зависаниям. acpi_osi="!Windows 2012" спасает. (Обрати внимание на восклицательный знак. Здесь он означает отрицание).

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

110. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от Аноним email(??) on 20-Окт-13, 13:35 
> Ох, я столько уже мучался с этим, что и забыл, что в
> первый раз это может выглядеть как глупая шутка.
> Суть в том, что ядро при загрузке вызывает (не знаю, как метод
> называется, пусть...

Ваш способ не сработал, но подтолкнул меня к другому - http://forums.linuxmint.com/viewtopic.php?f=49&t=137738

У меня запахало и с параметром acpi_osi=Linux, и с acpi_osi=Linux acpi_backlight=vendor (во втором случае, как мне показалось, запахало изменение яркости в настройках, а не только через горячие клавиши)


Только на экране нет ползунков регулировки (так сказать, наглядного дополнения к меняющейся яркости).

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

121. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от rshadow (ok) on 20-Окт-13, 14:40 
Не переживайте так, ваши мучения напрасны. В одном из следующих ядер все равно поломают опять...
Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

304. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от pavlinux (ok) on 27-Окт-13, 00:00 
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.

Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

139. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от northbear (??) on 20-Окт-13, 17:16 
Xosd вам в помощь. Благо Linux это не винды...
Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

2. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Crazy Alex (??) on 20-Окт-13, 00:14 
Все хорошо, но интересно, как у него со скоростью будет...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

83. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от Аноним (??) on 20-Окт-13, 06:50 
как у BPF
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +6 +/
Сообщение от Аноним (??) on 20-Окт-13, 00:28 
> Nftables, новой реализации пакетного фильтра, идущего на смену iptables

Вот есть iptables - проверенный годами, стабильный, притертый...
И тут на тебе новая шняга!, которая идет на смену iptables.
Да и еще с новым стрёмным синтаксисом.
Чё опять читать 100500 строковый ман? Тут бы старый дочитать :))

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от stalker37 email on 20-Окт-13, 00:35 
Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflow

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –8 +/
Сообщение от свободный бздун on 20-Окт-13, 00:37 
> Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflow

Гы-гы. Неосиляторы в треде.
Даёшь каждый год новый код!

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

12. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 01:04 
> Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflow

ipt_netflow давно пора слить в мейнстрим. Вот и повод появился.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

104. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:28 
Часть этих полезных модулей требует пересборки ведра, а это геморно (при его регулярном и автоматическом обновлениии). В сабже же же этим модули вынесут в юзерспейс. Профит!
Но скорость работы не в ядре вызывает ???
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

141. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +5 +/
Сообщение от Павел Одинцов email on 20-Окт-13, 17:47 
> Аха..а ещё к таблесам куча полезных модулей, например тот же самый ipt_netflow

Дерьма кусок Ваш ipt_netflow. Мы всеми силами выправляли его кривой код, рассказали автору как работают блокировки в ядре, прислали патчи.

Так нет же йопт, они в новой версии снова лезут создавать структуры ядра не из под лока! Оно и крашится в ответ через каждый час :/

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

157. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от stalker37 email on 20-Окт-13, 21:34 
а есть чем заменить? Только не говорите что покупать циску..
А так - 2 год крутится  на около провайдерской площадке под нагрузкой ~2gb (бондинг из 2 портов) -- ни 1 креша не было. Как креш воспроизвести?
Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

158. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Гость on 20-Окт-13, 23:56 
> а есть чем заменить? Только не говорите что покупать циску..
> А так - 2 год крутится  на около провайдерской площадке под
> нагрузкой ~2gb (бондинг из 2 портов) -- ни 1 креша не
> было. Как креш воспроизвести?

BSD и netgraph. =)

Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

164. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от stalker37 email on 21-Окт-13, 00:24 
аха.. смените ос,руки,планету...
Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

212. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 21-Окт-13, 15:58 
> аха.. смените ос,руки,планету...

Ну если так хочется воспроизвести креш - то и BSD поставишь, и netgraph настроишь.

Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

193. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от ананим on 21-Окт-13, 08:23 
>>Как креш воспроизвести?
>BSD и netgraph. =) 

В смысле "и креши появятся"?

Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

7. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от msa email(??) on 20-Окт-13, 00:43 
>> Nftables, новой реализации пакетного фильтра, идущего на смену iptables
> Вот есть iptables - проверенный годами, стабильный, притертый...
> И тут на тебе новая шняга!, которая идет на смену iptables.
> Да и еще с новым стрёмным синтаксисом.
> Чё опять читать 100500 строковый ман? Тут бы старый дочитать

iptables давно уже устарел, справедливо осмеян. Придется переучиватьсяю

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +4 +/
Сообщение от AnonuS on 20-Окт-13, 00:51 
> iptables давно уже устарел, справедливо осмеян. Придется переучиватьсяю

Чем конкретно он устарел, старый стал запинаться стал, раньше пакеты фильтровал, а теперь нет нет да и пропустит парочку по рассеянности ?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 00:59 
> Чем конкретно он устарел, старый стал запинаться стал, раньше пакеты фильтровал, а теперь нет нет да и пропустит парочку по рассеянности ?

Нет, просто уродец. Все попытки дальнейшего развития netfilter упирались в неимоверную кривизну x_tables.

Ждем аналогично экстерминатуса зоопарку им. Кузнецова (iproute2). С блекджеком и нормальной ограничивалкой трафика.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от AnonuS on 20-Окт-13, 01:08 
> Нет, просто уродец. Все попытки дальнейшего развития netfilter упирались в неимоверную кривизну x_tables.

Многим нравиться.

Как бы не народился ещё больший "уродец". Да и трудно всем угодить, один любит systemd, а другой например предпочитает свиной хрящик.


> Ждем аналогично экстерминатуса зоопарку им. Кузнецова (iproute2). С блекджеком и нормальной ограничивалкой трафика.

Ну да, прогресс не стоит на месте, и пожелания трудящихся ( "одминов" и программистов ) тоже...

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

22. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:31 
> Многим нравиться.

Мазохисты, сэр! Так давайте еще раз сделаем им больно, раз они это любят!

> Как бы не народился ещё больший "уродец".

Пока дизайн довольно красивый. Корень уродств x_tables растет еще из эпохи ipchains. Тогда еще думали, что несть протоколов, кроме IPv4, и несть ната, кроме маскарада. А потом выяснилось, что есть еще ARP, IPv6, Ethernet, всякие DNATы и SNATы. Старая оболочка все раздувалась и раздувалась...

> Да и трудно всем угодить,

А не надо кому-то угождать. Надо просто сделать технически лучше, чем было.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

35. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от AnonuS on 20-Окт-13, 02:09 
> А не надо кому-то угождать. Надо просто сделать технически лучше, чем было.

Дорогой анонимный брат Аноним, эта твоя позиция лично мне близка и понятна, и я могу её только поприветствовать. Если действительно удастся сделать "технически лучше, чем было", то я думаю и противники данного шага в конце концов осознают преимущества и открывшиеся перспективы. К тому же хочется надеяться, что поддержка нового кода, в конечном итоге, будет проще, а соответственно менее склонна к "забагованности".

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

209. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 15:54 
> Дорогой анонимный брат Аноним, эта твоя позиция лично мне близка и понятна, и я могу её только поприветствовать.

Судя по резкому изменению вашей позиции, вы успели сходить по ссылкам в новости =)

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

159. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Гость on 20-Окт-13, 23:58 
>> Многим нравиться.
> А не надо кому-то угождать. Надо просто сделать технически лучше, чем было.

Это уже попахивает изменой GNU/Linux. Вы так договоритесь до BSD way.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

207. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 21-Окт-13, 15:52 
> Это уже попахивает изменой GNU/Linux. Вы так договоритесь до BSD way.

BSD way - это когда не технически, а академически лучше. Но при этом никому нафиг не сдалось.

Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

86. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от Аноним (??) on 20-Окт-13, 07:48 
>> Нет, просто уродец. Все попытки дальнейшего развития netfilter упирались в неимоверную кривизну x_tables.
> Многим нравиться.
> Как бы не народился ещё больший "уродец". Да и трудно всем угодить,
> один любит systemd, а другой например предпочитает свиной хрящик.
>> Ждем аналогично экстерминатуса зоопарку им. Кузнецова (iproute2). С блекджеком и нормальной ограничивалкой трафика.
> Ну да, прогресс не стоит на месте, и пожелания трудящихся ( "одминов"
> и программистов ) тоже...

ну вы сравнили блин,  админы как раз знают bash отлично, и писать init в порядке вещей, да и для самопала часто вместо стандартного init выступает runit, поэтому на systemd и смотрят с недоверием. А вот с Nftables совсем другая штука, его давно ждали  и кучя админов в курсе что это. И он делался с оглядкой на FreeBSD. Так что новшество новшеству рознь.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

103. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:15 
> и писать init в порядке вещей

И это печально.

> часто вместо стандартного init выступает runit

Примерно один раз из десяти тысяч, не?

> И он делался с оглядкой на FreeBSD.

Фига с два.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

160. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Гость on 21-Окт-13, 00:03 
> ну вы сравнили блин,  админы как раз знают bash отлично

Ой ли? over 99% на яндексовские задачи правильно ответить не могут.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

208. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 21-Окт-13, 15:53 
> Ой ли? over 99% на яндексовские задачи правильно ответить не могут.

Видимо, вин- и убунтоадмины.

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

14. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:08 
> Вот есть iptables - проверенный годами, стабильный, притертый...

Дедушка умер, похороните его уже.

> Да и еще с новым стрёмным синтаксисом.

А вот бздуны от такого синтаксиса кипятком писают, например.

> Чё опять читать 100500 строковый ман?

Не нравится - вперед, в дворники.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

18. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:18 
> Не нравится - вперед, в дворники.

Это вот ты сейчас так защищаешь ТО, чем еще ниразу не пользовался и руками не щупал.
Я говорю о стабильности и надёжности, проверенных вещах. Ты говоришь о бздунах и дворах.
Делайте выводы господа :)

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

21. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:25 
>> Не нравится - вперед, в дворники.
> Это вот ты сейчас так защищаешь ТО, чем еще ниразу не пользовался и руками не щупал.

Откуда ты знаешь, мой юный друг? Может быть, я слежу за этим проектом с 2009 года, когда он только появился?

> Я говорю о стабильности и надёжности, проверенных вещах.

Хрущевки тоже проверены временем. Но это не значит, что там нужно покупать квартиру :)

> Делайте выводы господа :)

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 01:38 
> Откуда ты знаешь, мой юный друг? Может быть, я слежу за этим проектом с 2009 года, когда он только появился?

Это очень замечательно, что на опеннете есть человек, который следил за этим проектом с 2009 года (~4 года, так?)
Буду очень признателен если ты поделишься своими познаниями и возможно развеешь все мои домыслы.

> Хрущевки тоже проверены временем. Но это не значит, что там нужно покупать квартиру :)

Железный аргумент. С нетерпением жду более детальной выкладки материала по вопросу Nftables

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

Человеку свойственна лень. Вам нет?

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

32. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 02:06 
> Это очень замечательно, что на опеннете есть человек, который следил за этим проектом с 2009 года (~4 года, так?)

Четыре с половиной (официальный анонс был весной). Но в 9-11 годах следить было особо не за чем - несколько коммитов в год.

> Буду очень признателен если ты поделишься своими познаниями и возможно развеешь все мои домыслы.

На всезнание не претендую, но насчет ключевых моментов вроде в курсе. Спрашивай.

>> Хрущевки тоже проверены временем. Но это не значит, что там нужно покупать квартиру :)
> Железный аргумент.

Не менее железный, чем "X работало 10 (20, 30, ...) лет, значит, X нельзя трогать".

> Человеку свойственна лень. Вам нет?

Чем удобнее и логичнее инструмент, тем больше простора для лени он предоставляет.
Там, где виндyзятник будет тысячу раз щелкать мышкой, юниксоид напишет скрипт. (На что виндyзятник, конечно, ответит - "а мне лень ваши скрипты изучать, я лучше мышкой". Что ж, это его выбор)

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

89. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 08:25 
> На всезнание не претендую, но насчет ключевых моментов вроде в курсе. Спрашивай.

Как оно из байткода выводит список текущих правил в человекопонятном виде (по аналогии с 'iptables -t nat -L POSTROUTING')? Можно ли засунуть в байткод правила, которые стандартная cli не пережует или интерпретирует неверно?

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

105. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:29 
>> На всезнание не претендую, но насчет ключевых моментов вроде в курсе. Спрашивай.
> Как оно из байткода выводит список текущих правил в человекопонятном виде (по аналогии с 'iptables -t nat -L POSTROUTING')?

Путем декодирования, очевидно же. См. src/netlink.c, list_chain_cb.

> Можно ли засунуть в байткод правила, которые стандартная cli не пережует или интерпретирует неверно?

Полагаю, можно. Только зачем ломать юзерспейнсую программу (ну выдаст nft сегфолт) через редактирование памяти ядра?

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

118. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 14:04 
Да что-то гложат меня смутные сомнения. Теоретически, байткодом можно много чего наворотить, и хорошо если оно при просмотре хотя бы сегфолт выдаст, а не спрячет правило от админа. И ведь даже запрет на загрузку модулей не защитит от такой уязвимости...

В общем, как-то слегка подозрительно всё это звучит.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

168. "В ядре Linux 3.13 ожидается появление нового пакетного..."  –1 +/
Сообщение от arisu (ok) on 21-Окт-13, 00:44 
> Да что-то гложат меня смутные сомнения. Теоретически, байткодом можно много чего наворотить,
> и хорошо если оно при просмотре хотя бы сегфолт выдаст, а
> не спрячет правило от админа. И ведь даже запрет на загрузку
> модулей не защитит от такой уязвимости…

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

ну, или проще: НЕ РАБОТАЙ ПОД РУТОМ!

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

213. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:01 
> Да что-то гложат меня смутные сомнения. Теоретически, байткодом можно много чего наворотить,
> и хорошо если оно при просмотре хотя бы сегфолт выдаст, а
> не спрячет правило от админа. И ведь даже запрет на загрузку
> модулей не защитит от такой уязвимости...

Байт-кодом, который имеет доступ только к сетевым пакетам? Ну-ну.
При наличии рутового доступа те же вещи можно сделать гораздо проще (например, на raw-сокетах, как в pcap).

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

230. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 22:17 
> Байт-кодом, который имеет доступ только к сетевым пакетам? Ну-ну.
> При наличии рутового доступа те же вещи можно сделать гораздо проще (например,
> на raw-сокетах, как в pcap).

Байткодом, который имеет доступ к фаерволу. Можно разрешить много лишнего на сетевом уровне, которое хрен отследишь снифером с этой же машины. Этакий руткит в дефолтной поставке - никаких левых процессов, подгружать левые модули ядра больше не нужно.

Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

276. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 20:50 
> Байткодом, который имеет доступ к фаерволу. Можно разрешить много лишнего на сетевом уровне, которое хрен отследишь снифером с этой же машины.

Почему? Через тот же pcap - никаких проблем. У фаервола и raw-сокетов один и тот же сетевой стек, а не два независимых.

> Этакий руткит в дефолтной поставке - никаких левых процессов, подгружать левые модули ядра больше не нужно.

Для pcap тоже никаких модулей подгружать не нужно.

А еще можно хранить злохакерские явки и пароли в параметрах sysctl, например. Примерно такая же страшная угроза.

Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

299. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 23-Окт-13, 10:39 
> Почему? Через тот же pcap - никаких проблем. У фаервола и raw-сокетов
> один и тот же сетевой стек, а не два независимых.

Это я просто предположил так, какие там возможности у этого байткода и фильтра в целом - я не знаю. Если я ошибся, то хорошо. Но всё-равно, снифером ведь надо ещё знать что искать в общем потоке трафика.


> Для pcap тоже никаких модулей подгружать не нужно.

Я пытаюсь акцентировать внимание на том, что - возможно - появится встроенная возможность скрыть некоторые правила фаервола от админа. Конечно, удобнее написать программу, которая будет работать в отдельном процессе, но её будет видно в списках процессов и в netstat (руткиты сейчас не рассматриваем - это отдельная история).

Опасные правила фаервола и сейчас можно спокойно написать, но они 100% отобразятся в выхлопе iptables в легко понятном человеку виде (про руткиты сейчас, опять же, не вспоминаем).


> А еще можно хранить злохакерские явки и пароли в параметрах sysctl, например.
> Примерно такая же страшная угроза.

Про sysctl не понял. Что там можно хранить?

Ответить | Правка | ^ к родителю #276 | Наверх | Cообщить модератору

127. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:01 

> Путем декодирования, очевидно же. См. src/netlink.c, list_chain_cb.

А время вывода over9000 строк не станет больше чем просто вывод по сути текстовой информации ?
Если каждую строчку придется декодировать.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

210. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 15:56 
> А время вывода over9000 строк не станет больше чем просто вывод по сути текстовой информации ?
> Если каждую строчку придется декодировать.

Большие наборы правил удобнее сворачивать в множества (sets), которые декодируются вполне тривиально (хеш->значение).

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

140. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от northbear (??) on 20-Окт-13, 17:24 
> Человеку свойственна лень. Вам нет?

Человек которому свойственна лень больше, чем можно себе это позволить, неизбежно превращается в планктон и становится чужой едой...

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

97. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от VolanD (ok) on 20-Окт-13, 11:25 
>> Не нравится - вперед, в дворники.
> Это вот ты сейчас так защищаешь ТО, чем еще ниразу не пользовался
> и руками не щупал.
> Я говорю о стабильности и надёжности, проверенных вещах. Ты говоришь о бздунах
> и дворах.
> Делайте выводы господа :)

Небось еще сендмылом почту рулите?

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

109. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от Аноним (??) on 20-Окт-13, 13:33 
> Не нравится - вперед, в дворники.

Павлик, залогинься.
>А вот бздуны

Интересы 1%  никого не волнуют ))

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

116. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Аноним (??) on 20-Окт-13, 13:46 
> Павлик, залогинься.

То, что личности с ограниченными интеллектуальными возможностями должны заниматься только простыми работами - факт, очевидный не только вашему Павлику.

> Интересы 1%  никого не волнуют ))

Такой же 1%, как и у линуксоидов. Ничем не хуже.

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

25. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Seclorum (??) on 20-Окт-13, 01:38 
> Вот есть iptables - проверенный годами, стабильный, притертый...

И неподдерживающий кучу сетевых протоколов...


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

128. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:03 
>> Вот есть iptables - проверенный годами, стабильный, притертый...
> И неподдерживающий кучу сетевых протоколов...

Каких например ? каких из тех, с коими реально сталкиваются сисадмины ?
igrp, ospf, rip ?

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

211. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 15:57 
> Каких например ? каких из тех, с коими реально сталкиваются сисадмины ?

Начнем с простых: ethernet, ARP/RARP, IPv6 =)

Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

94. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от lucentcode (ok) on 20-Окт-13, 11:09 
Не надо ворчать. Если вы профессионал своего дела - вы каждый день маны читаете. Одним больше, одним меньше - какая разница? А удобочитаемые правила, и ускорение разбора этих правил за счёт использования бат-кода - это хорошо. Как и то, что основная нагрузка на разбор правил теперь в user space. Чем меньше кода работает на уровне ядра - тем лучше. Больше кода - больше вероятность что в нём есть уязвимости.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

111. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –7 +/
Сообщение от Anonim (??) on 20-Окт-13, 13:37 
> Если вы профессионал своего дела - вы каждый день маны читаете.

Маны каждый день читают админишки недоделаные, профессионалы их пишут.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

115. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:44 
> Маны каждый день читают админишки недоделаные, профессионалы их пишут.

Это типа пропаганда расовой ненависти быдлoкодеров к админам?

Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

130. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:04 
> теперь в user space. Чем меньше кода работает на уровне ядра
> - тем лучше.

Кстати сам Линус не считает что в линуксе должно быть микроядро, а все что можно по максимуму - вынесено за пределы ядра в его модули.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

142. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от lucentcode (ok) on 20-Окт-13, 18:18 
> Кстати сам Линус не считает что в линуксе должно быть микроядро, а
> все что можно по максимуму - вынесено за пределы ядра в
> его модули.

Сам Линус никогда не был авторитетом в области проектирования и архитектуры ОС. Он так бы и остался не самым умным(он сам о себе так говорил в беседе с финскими студентами) студентом, который изобрёл ещё один велосипед. Если бы не стечение обстоятельств. Парни из Беркли, создавшие 4.4BSD огребли проблемы от патентных троллей в 1992 году, и срочно нужен был свободный клон Unix ему на замену. Minix не мог заменить 4.4BSD, GNU Hurd уже тогда был мертвеннорожденным проектом. И именно благодаря этому стечению обстоятельств в тот момент Linux стал уникальным и незаменимым. Он быстро занял место 4.4BSD, а потом потомки ОС из Беркли уже не могли его догнать. Они сбавили темп, и навсегда потеряли своё место под Солнцем. Не нужно с Линуса делать авторитета. Он написал ОС, которая работала. Но над ядром трудилось много гораздо более квалифицированных программистов. Линус - икона, как Стив Джобс или Билл Гейтс. Но, как и они, он далеко не самый авторитетный специалист в области IT. Я бы не стал считать его мнение(как и мнение Гейтса или Джобса), особо авторитетным.

Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

144. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Andrey Mitrofanov on 20-Окт-13, 18:43 
>> Кстати сам Линус не считает что в линуксе должно быть микроядро, а
>> все что можно по максимуму - вынесено за пределы ядра в
>> его модули.
>Парни из Беркли, создавшие 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лоте уверены -- авторитет.

Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

147. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от lucentcode (ok) on 20-Окт-13, 19:17 
То, что все потомки 4.4BSD никогда не догонят теперь Linux по популярности(Mac OS X считать потомком 4.4BSD мы не можем, это ОС с другой архитектурой(как раз более близкой к микроядерным)), это уже неоспоримый факт. Своё время фанбои подделий из Беркли упустили.

> Зато как тролит! Пaцаны на бoлоте уверены -- авторитет.

Линус - в первую очередь символ. Это человек-икона. А ещё он оказался гениальным организатором. И в этой роли(координатора и вдохновителя) он приносит намного больше пользы, чем в роли рядового программиста. Координировать работу тысяч программистов - это программисткий скил высшего уровня. При этом Линус - редкостный троль. Я бы не стал считать Линуса хорошим специалистом в области архитектуры ОС.

Да это и к лучшему, что он(в отличии от Столлмана и Таннебаума) так и не осознал, что такое хорошая архитектура. Потому что увлекшись перфекционизмом, он бы никогда не создал работоспособное ядро. Он бы испугался массштаба той работы, которую нужно было проделать. Или погряз бы в дебатах на тему совершенного кода, и не менее совершенной, архитектуры. Но то, что было хорошо для быстрого развития ядра(особенно на ранних этапах) - не будет оптимальным, когда ядро разростётся до невероятных массштабов. Оно и так уже слишком жирное. Рано или поздно всё лишнее начнут выносить из ядра в юзерспейс. Разрабы netfilter просто раньше других осознали это.

Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

148. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Адекват (ok) on 20-Окт-13, 19:58 
> Сам Линус никогда не был авторитетом в области проектирования и архитектуры ОС.

И тем не менее - у него были аргументы того, каким должно быть _его_ ядро.
Я вот например считаю, что если что-то вынести за пределы ядра, то это облегчит задачу для всякого рода хакеров и крекеров, по запуску своего кода с привилегиями ядра. Как видно из статьи, цитата:


правила фильтрации компилируются в пространстве пользователя в  байткод и передаются в ядро через API Netlink

То есть теперь не нужны права рута, чтобы сообщать ядру какие-то параметры.
Я вижу 2 потенциальные угрозы безопасности:
То что можно будет запустить вредоносный код с правами ядра, найдя уязвимость в ядре и передав ядру "специально сформированный байт-код", но запустив вредоносную программу с правами пользователя.
Второе - "специальная связующая интерфейсная библиотека libnl" является дополнительным звеном в цепи, и сама по себе представляет источник уязвимости - теоретически ее можно подменить на такую же, но с бекдором.

Все что я написал трудно выполнимо, но все-таки легче, чем в случае с iptables, который является надстройкой над netfilter - который монолитно вшит в ядро.

Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

149. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от lucentcode (ok) on 20-Окт-13, 20:07 
>[оверквотинг удален]
> Я вижу 2 потенциальные угрозы безопасности:
> То что можно будет запустить вредоносный код с правами ядра, найдя уязвимость
> в ядре и передав ядру "специально сформированный байт-код", но запустив вредоносную
> программу с правами пользователя.
> Второе - "специальная связующая интерфейсная библиотека libnl" является дополнительным
> звеном в цепи, и сама по себе представляет источник уязвимости -
> теоретически ее можно подменить на такую же, но с бекдором.
> Все что я написал трудно выполнимо, но все-таки легче, чем в случае
> с iptables, который является надстройкой над netfilter - который монолитно вшит
> в ядро.

В целом, вы правы. Но не думаю, что любой пользователь может компилировать правила для файрвола. Думаю, данное действие будет доступно только пользователям определённой группы.

Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

169. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +2 +/
Сообщение от arisu (ok) on 21-Окт-13, 00:53 
> То есть теперь не нужны права рута, чтобы сообщать ядру какие-то параметры.

а вот с этого места — подробней давай. особенно интересно, чем это *принципиально* отличается от пинания ядра на предмет «распарзи вот этот вход» (кроме того, что парзер как раз и убрали).

> То что можно будет запустить вредоносный код с правами ядра, найдя уязвимость
> в ядре и передав ядру «специально сформированный байт-код», но запустив
> вредоносную программу с правами пользователя.

точно так же, как *теоретически* это можно сделать, накормив парзер кривыми входными данными. только парзер сложнее в отладке, потому что в нём больше кода.

> теоретически ее можно подменить на такую же, но с бекдором

это означает, что рутовый доступ к системе уже есть. а, следвательно, ни о какой безопасности речь уже не идёт.

> который монолитно вшит в ядро

см. выше про парзер. чем меньше в ядро «вшито» кода — тем легче его отладить.

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

Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

196. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от Аноним (??) on 21-Окт-13, 10:18 
некомпетентность Линуса - это миф
который подогревается всеми, кому не лень, в том числе и нашими бывшими разработчиками линуксового ядра
не стоит забывать, что именно Линус написал первые версии ядра, файловой системы
что именно линус координировал и сам переписывал  первые модули ядра, написанные другими разработчиками
то, что он сейчас ничего не пишет, в этом нет ничего удивительного - нельзя обьять необьятное, тем более что что ядро начинает разрастаться до необьятных размеров
Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

229. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от lucentcode (ok) on 21-Окт-13, 19:35 
> некомпетентность Линуса - это миф
> который подогревается всеми, кому не лень, в том числе и нашими бывшими
> разработчиками линуксового ядра
> не стоит забывать, что именно Линус написал первые версии ядра, файловой системы
> что именно линус координировал и сам переписывал  первые модули ядра, написанные
> другими разработчиками
> то, что он сейчас ничего не пишет, в этом нет ничего удивительного
> - нельзя обьять необьятное, тем более что что ядро начинает разрастаться
> до необьятных размеров

Не спорю. Совсем некомпетентый человек не мог бы проверять чужой код, и координировать столько лет работу над ядром. Но не факт, что Линус - хороший системынй архитектор. Нужно у него самого спросить, что он думает по поводу своей компетентности в данном вопросе.


Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

162. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Гость on 21-Окт-13, 00:18 
> Не надо ворчать. Если вы профессионал своего дела - вы каждый день
> маны читаете.

А пацанам не нужен нормальный l7-filter, имя что-нить попроще, для домашнего роутера.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

99. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Aleks Revo (ok) on 20-Окт-13, 12:11 
К 2113 году, когда в стабильную ветку будут переведены ядра 3.13 всё будет уже проработано и организовано ;-)
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

107. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:31 
> К 2113 году, когда в стабильную ветку будут переведены ядра 3.13

Всего лишь к 2014.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

126. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от XoRe (ok) on 20-Окт-13, 15:51 
>> Nftables, новой реализации пакетного фильтра, идущего на смену iptables
> Вот есть iptables - проверенный годами, стабильный, притертый...
> И тут на тебе новая шняга!, которая идет на смену iptables.
> Да и еще с новым стрёмным синтаксисом.
> Чё опять читать 100500 строковый ман? Тут бы старый дочитать :))

s/iptables/ipchains/g ну вы поняли... )

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

150. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от тигар (ok) on 20-Окт-13, 20:10 
примерно также когда-то давно поклонники ipchains думали.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

192. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 21-Окт-13, 08:21 
Совсем не так.
Вам, бсдишнегам, трудно понять, что iptables был просто логическим продолжением ipchains.
Увеличилась функциональность, добавились опции и... всё.
Проблем с переходом не возникло.
Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

214. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:04 
> Совсем не так.
> Вам, бсдишнегам, трудно понять, что iptables был просто логическим продолжением ipchains.
> Увеличилась функциональность, добавились опции и... всё.
> Проблем с переходом не возникло.

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

Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

262. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 22-Окт-13, 14:21 
Трудно представить, чтобы вы, любители анимэ, сделали с старичком колесом.
Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

278. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 20:53 
> Трудно представить, чтобы вы, любители анимэ, сделали с старичком колесом.

С колесом - не так много. А вот повозки эпохи первых колес, несмотря на их стабильность, притертость и беспроблемность, уже отошли в историю.

Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

283. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 22-Окт-13, 21:10 
При этом колёса просто модифицировались, а не изобретались по-новой.
Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

288. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 21:26 
> При этом колёса просто модифицировались, а не изобретались по-новой.

Человек - это модифицированная амеба.

Ответить | Правка | ^ к родителю #283 | Наверх | Cообщить модератору

290. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Michael Shigorin email(ok) on 22-Окт-13, 21:31 
>> При этом колёса просто модифицировались, а не изобретались по-новой.
> Человек - это модифицированная амеба.

Пожалуйста, если уж очень неймётся -- делитесь такими откровениями (да и вообще) где-нить ещё, и так уже опять на триста сообщений флейм раздули...

Ответить | Правка | ^ к родителю #288 | Наверх | Cообщить модератору

9. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от AnonuS on 20-Окт-13, 00:59 
> Ключевой особенностью Nftables является применение идеи, близкой к реализации BPF (Berkeley Packet Filters) - правила фильтрации компилируются в пространстве пользователя в байткод и передаются в ядро...
> Выполнение правил с использованием конечного автомата вместо применения логики сопоставления позволяет сократить размер кода фильтрации, работающего на уровне ядра...

Выглядит положительным начинанием, но не опасна ли эта затея с байт-кодом. Кто может пояснить на пальцах и успокоить ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 01:03 
> Выглядит положительным начинанием, но не опасна ли эта затея с байт-кодом. Кто может пояснить на пальцах и успокоить ?

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

96. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от Мяут (ok) on 20-Окт-13, 11:16 
Только Lua, только хардкор!
Нет, серьезно: http://www.opennet.dev/openforum/vsluhforumID3/92243.html
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

170. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +4 +/
Сообщение от arisu (ok) on 21-Окт-13, 01:02 
> Выглядит положительным начинанием, но не опасна ли эта затея с байт-кодом.

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

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

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

опять для альтернативщиков: это всё были упрощения и логические выводы, не основаные на детальном исследовании кода новой реализации. если есть возражения по существу, основаные на коде — добро пожаловать, показывайте, это будет полезно.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:05 
Твою дивизию! Я только что окончил читать мануал к iptables на 600 страниц...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +6 +/
Сообщение от Sinot (ok) on 20-Окт-13, 01:09 
А зачем? Я вот тоже опасался сложности написания правил iptables, а выяснилось, что основ там на пол странички, а все остальное изучается исключительно по необходимости.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

19. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:21 
> Твою дивизию! Я только что окончил читать мануал к 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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

20. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:24 
Тогда какого Х*я ваще было синтаксис менять, раз всего названия сущностей были изменены?!
Шо за треш!
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

23. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:34 
> Тогда какого Х*я ваще было синтаксис менять, раз всего названия сущностей были
> изменены?!
> Шо за треш!

Внутри тоже кой-чего поменяли. Например, слили четыре гигантских куска дублирующегося кода (ip_tables, ip6_tables, arp_tables и ebtables) в один.
А синтаксис - так, за компанию. Тем более, что действительно напрашивалось.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

26. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:44 
> А синтаксис - так, за компанию. Тем более, что действительно напрашивалось.

Кому оно напрашивалось? Вот посмотрите на новый синтаксис с точки зрения эргономики - все сливается... не хватает разделителей (типа '-')... Трудно читабельно, и не похоже на стандартный синтаксис CLI.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

30. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +7 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:59 
> Кому оно напрашивалось? Вот посмотрите на новый синтаксис с точки зрения эргономики
> - все сливается... не хватает разделителей (типа '-')... Трудно читабельно, и

У вас, видимо, браузер не отображает пробелы. Наверное, стоит написать багрепорт разработчикам.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

31. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от Аноним (??) on 20-Окт-13, 02:03 
Иди отсюда, арчеребёнок. Синтаксис иптаблес лучше
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

33. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 02:08 
> Иди отсюда, арчеребёнок.

Не брюзжи, слакодедуля :)

> Синтаксис иптаблес лучше

Чем грузины? Или чем армяне?

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

41. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 02:50 
Тем, что он соответсвует POSIX стандарту коммандной строки.
Кстати, как там о добавлении правил из коммандной строки? Порой бывает очень нужно, не перегружать же все 100500 из-за одного правила.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

45. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 03:00 
Зыж
>Кстати, как там о добавлении правил из коммандной строки?

С точки зрения лаконичности и удобства имеется в виду.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

46. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 03:03 
> Тем, что он соответсвует POSIX стандарту коммандной строки.

Я бы не сказал, что для фаервола это достоинство.
Вот ты бы очень обрадовался, если бы твою речь ограничили синтаксисом POSIX commandline?

> Кстати, как там о добавлении правил из коммандной строки?

Сходи по ссылке, например. А то не прочитал нифига, а осуждать уже лезешь.

> Порой бывает очень нужно, не перегружать же все 100500 из-за одного правила.

В силу структуры iptables, невозможно добавить/удалить одно правило, не поменяв весь набор.
Правила хранятся в ядре в виде блоба, который формируется утилитами в userspace. При изменении одного правила, его нужно генерировать с нуля.
Именно поэтому разработчики iptables рекомендуют вместо скриптов с кучей команд iptables использовать iptables-restore (см. Jan Engelhardt, Towards to the perfect ruleset).

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

47. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 03:08 
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:

С тех пор ничего не поменялось.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

50. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 03:32 
ссылочкой надеюсь не трудно будет поделиться?
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

84. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Ананас on 20-Окт-13, 07:29 
http://inai.de/documents/Perfect_Ruleset.pdf
Ответить | Правка | Наверх | Cообщить модератору

92. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 10:25 
верно. что мешало ранее так сделать?

зыж
но вот это из разряда вредных советов:
>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)
>{…

все операции там вроде как атомарны и блокируются.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

108. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:33 
> все операции там вроде как атомарны и блокируются.

Ага-ага, каждый раз при перезагрузке правил блокируется сетевой стек.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

122. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 14:43 
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;
Вся, уже скомпилированная(!!!) таблица копируется из юзер-спейса в ядро, только потом(!!!) блокировка, потом копирование указателей(!!!) и разблокировка.
Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

49. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 03:14 
>Я бы не сказал, что для фаервола это достоинство.

Как примут ваш стандарт "не_сказал_бы" на правила командной строки, тогда и поговорим.
А заодно и реализуют кучку библиотек (от баша, до с++) по разбору параметров командной строки.
А то уже существует масса фронт-эндов от популярных, до моих собственных.
>Сходи по ссылке, например. А то не прочитал нифига, а осуждать уже лезешь.

Я не зря после комменты "зыж" добавил.
Попробуйте там доказать насколько сабж лаконичней, удобней и грамотней получится.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

53. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 03:41 
> Как примут ваш стандарт "не_сказал_бы" на правила командной строки, тогда и поговорим.

Строка есть? Есть. Командует? Командует. Что тебе еще надо?

> А заодно и реализуют кучку библиотек (от баша, до с++) по разбору параметров командной строки.

Ты решил сделать несколько альтернативных реализаций /sbin/nft на разных языках?
Тогда фиг с ними, с параметрами командной строки! Лучше покажи, как ты трансляцию в байткод на баше напишешь. Это ж дичайшей красоты и понятности код будет! Уже побежал за попкорном.

> А то уже существует масса фронт-эндов от популярных, до моих собственных.

Основная причина существования этих фронт-эндов - POSIX-совместимый синтаксис командной строки :)

> Попробуйте там доказать насколько сабж лаконичней, удобней и грамотней получится.

Сначала я хочу послушать твое доказательство, что твой фронтенд удобнее, хотя бы для тебя. Страниц на пять хотя бы.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

57. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 03:49 
>Строка есть? Есть. Командует? Командует. Что тебе еще надо?

Я что, не доступным вам языком написал?
Мне нужен стандартный способ разбора командной строки.
А также кучка библиотек (от баша, до с++) по разбору параметров командной строки, чтобы самому не изобретать велосипед.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

58. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 03:52 
зыж
>> А заодно и реализуют кучку библиотек (от баша, до с++) по разбору параметров командной строки.
>Ты решил сделать несколько альтернативных реализаций /sbin/nft на разных языках?
>Тогда фиг с ними, с параметрами командной строки!

Вам (кстати, это от природной скромности вы на «ты» перешли?) понятен смысл слова front-end?

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

62. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Аноним (??) on 20-Окт-13, 03:57 
> Вам (кстати, это от природной скромности вы на «ты» перешли?)

Просто не поворачивается язык человеку с такими детскими манерами писать "ты". Если на самом деле ты старый дедуля - считай за комплимент :)

> понятен смысл слова front-end?

Боюсь, что смысл этого слова не доступен как раз тебе.
Фронтенд должен не _читать_ командную строку nft, а _писать_ ее.
Читать он будет ее вывод и код выхода. Кстати, как твои фронтенды ухитряются работать без специальных библиотек, парсящих вывод iptables?

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

67. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 04:13 
>Просто не поворачивается язык человеку с такими детскими манерами писать "ты".

Э… А не наоборот? Поворачивается, как у прыщавого подростка в сложный период своего самоутверждения.
Заговариваться сталИ, дедуля? :D
>> понятен смысл слова front-end?
>Боюсь, что смысл этого слова не доступен как раз тебе.
>Фронтенд должен не _читать_ командную строку nft, а _писать_ ее.

Именно! (generate a perfect hash function from a key set)
У меня мало желания работать с 2-я разными синтаксисами и служить между ними переводчиком.
>Кстати, как твои фронтенды ухитряются работать без специальных библиотек, парсящих вывод iptables?

Путаете параметры командной строки и вывод stdout.
Что для ребёнка, упорствующего в своём праве хамить, не удивительно

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

74. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 04:36 
> Э… А не наоборот? Поворачивается, как у прыщавого подростка в сложный период своего самоутверждения.

Ага, значит я не ошибся с определением твоего возраста.

> Именно! (generate a perfect hash function from a key set)

ШТО? Зачем тебе хеш?

> У меня мало желания работать с 2-я разными синтаксисами и служить между ними переводчиком.

А ты и не служи. Юзай iptables, оно все равно потом (после допиливания nftables) будет транслироваться в nft. А вот обратно низя - iptables просто не умеет, например, низкоуровневой работы с хуками netfilter (поэтому глобальные цепочки там невозможны).

> Путаете параметры командной строки и вывод stdout.

По-моему, это ты их путаешь.

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

78. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 04:54 
Ззыж
Ах да! Воскресенье. :D
Ответить | Правка | Наверх | Cообщить модератору

61. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 03:53 
> Я что, не доступным вам языком написал?
> Мне нужен стандартный способ разбора командной строки.

Зачем тебе разбирать командную строку программы, которая уже написана? Чтобы сделать велосипед?

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

68. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 04:20 
Мне нужно её формировать.
Желательно однообразным, стандартным способом.
В худшем случая имея хотя бы какой-то стандарт.


зыж
Например, при стандартном способе обработки я могу построить релевантные отношения между параметрами и их доступном в данном случае количестве.
Т.е. если указан -а, то параметров может быть не более 10, доступны -б, -с… и т.д.
В сабжевом случае уже бы xml использовали что ли, его валидность хотя бы можно проверить.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

72. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 04:32 
> Например, при стандартном способе обработки я могу построить релевантные отношения между параметрами и их доступном в данном случае количестве.
> Т.е. если указан -а, то параметров может быть не более 10, доступны -б, -с… и т.д.

nft ничем в этом плане не отличается от iptables (кроме отсутствия минусов).

Или ты не про командную строку, а про дамп правил?

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

77. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 04:52 
>nft ничем в этом плане не отличается от iptables (кроме отсутствия минусов).

Докажи.
Хотя бы на примере из сабжа выше — как проверить валидацию параметров до запуска. Формально конечно, не смысл самих правил.

Зыж
>а про дамп правил?

Во, о чём и речь. Пошли какие-то свои термины, своего (нарождающегося на ходу) стантарда, своих правил.…
Как проверить корректность сформированной командной строки ДО запуска?

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

93. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от kem email on 20-Окт-13, 10:46 
а как это сделать в текущем интерфейсе iptables ?
Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

102. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 13:01 
как и у любого другого приложения, поддерживающего опции командой строки в стиле стандарта 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/ (там же и все мотивы, с которыми я солидарен)

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

217. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:12 
Откройте для себя Bison.
Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

232. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 02:05 
И пишите свои парсеры вместо того, что отлажено за пару десятков лет? Ну-ну, желаю вам так и делать. наслаждайтесь граблями.
Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

235. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 02:16 
> И пишите свои парсеры вместо того, что отлажено за пару десятков лет?
> Ну-ну, желаю вам так и делать. наслаждайтесь граблями.

да за каким фигом тебе вообще парзить правила-то? генерируем не приходя в сознание, а потом парзим, чтобы понять, что там нагенерилось?

я вот достаточно давно использую ferm. в том числе его правилами заведует несколько роботов. представь: мне ни разу не понадобилось парзить фермовые правила. вообще. только генерировать и собирать в кучку (что, кстати, сильно облегчается наличием в ferm такой штуки, как include).

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

а зачем парзить параметры комстроки для файрвола? опять кто-то не приходя в сознание нагенерировал? могу посоветовать таки прийти в сознание и хранить нужные опции в более удобном виде, из которого параметры и создавать.

Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

240. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от ананим on 22-Окт-13, 03:15 
>> И пишите свои парсеры вместо того, что отлажено за пару десятков лет?
>> Ну-ну, желаю вам так и делать. наслаждайтесь граблями.
> да за каким фигом тебе вообще парзить правила-то?

Забавно. Это ты ж так делать предложил! :D

Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

259. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 13:18 
Честно говоря, конкретно мне парсить не приходилось, но вполне могу представить ситуацию, когда надо сделать что-то вроде аудита, то есть собрать все правила в кучу и посмотреть, каким получается результирующее условие.

Впрочем, меня гораздо больше раздражает "человекочитаемый" синтаксис как раз в плане хреновой читаемости человеком. Как по мне, неалфавитные разделители строки на отдельные единицы - большое благо. Проще нужный кусок увидеть.

С другой стороны - если это внешняя тулза правила компилирует - наверняка останется вариант с синтаксисом a-la iptables.

Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

267. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 18:24 
> Честно говоря, конкретно мне парсить не приходилось, но вполне могу представить ситуацию,
> когда надо сделать что-то вроде аудита, то есть собрать все правила
> в кучу и посмотреть, каким получается результирующее условие.

это — решение задачи, которая ещё даже не появилась. при этом у меня есть стойкое мнение, что решать её намного проще будет при помощи «отладочной инфы» в полученом байткоде и юзермодового же симулятора с execution trace. которые наглядно покажут, сквозь какие правила что прошло.

> Впрочем, меня гораздо больше раздражает «человекочитаемый» синтаксис как раз в плане хреновой
> читаемости человеком. Как по мне, неалфавитные разделители строки на отдельные единицы
> — большое благо. Проще нужный кусок увидеть.

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

> С другой стороны — если это внешняя тулза правила компилирует — наверняка
> останется вариант с синтаксисом a-la iptables.

ну да. для тех, кому жаль лет, потраченых на «$@#^%@%@».

Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

268. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 18:26 
p.s. забавно повоевать «с другой стороны», да.
Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

286. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 21:13 
> Впрочем, меня гораздо больше раздражает "человекочитаемый" синтаксис как раз в плане хреновой
> читаемости человеком. Как по мне, неалфавитные разделители строки на отдельные единицы
> - большое благо. Проще нужный кусок увидеть.

Почему же вы не пользуетесь ими в обычной речи? Не ставите -- перед каждым словом, и всякие ))) или ... после каждой фразы?
Получается какой-то двойной стандарт - говорите, что удобно и вообще зашибись, но сами воздерживаетесь.

Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

284. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Аноним (??) on 22-Окт-13, 21:11 
> И пишите свои парсеры вместо того, что отлажено за пару десятков лет?

Почему-то в этом "отлаженном за пару десятков лет" до сих пор продолжают находить ошибки, связанные с тем, что iptables-save генерирует некорректные (даже с точки зрения iptables-restore) дампы. Одна из причин этого - использование для дампов синтаксиса команд POSIX.

> Ну-ну, желаю вам так и делать. наслаждайтесь граблями.

Как показывает практика, использование "отлаженных за пару десятков лет" решений дает ничуть не меньше граблей =)

Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

236. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 02:18 
> Откройте для себя Bison.

кстати, закройте для себя bison и откройте для себя lemon.

Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

260. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 13:22 
Ну хвалятся они прикольно, а что оно _на_практике_ даёт по сравнению с бизоном? SQlite - это, конечно, неплохая заявка, но они вообще экзотику любят - тот же Fossil взять.
Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

269. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 18:37 
> Ну хвалятся они прикольно

кто и чем «хвалится»? O_O

> а что оно _на_практике_ даёт по сравнению с бизоном?

как минимум — парзер, который можно кормить токенами, а не парзер, который из своего цикла настырно токены требует. синтаксис несколько удобней. выхлоп чуть компактней. есть удобная фича «деструктор токена» — вызов функции-деструктора, когда токен больше не нужен. ну и да: можно со своей софтиной его носить, там один сишный файл — иногда это удобно.

> SQlite — это, конечно, неплохая заявка, но они вообще экзотику
> любят — тот же Fossil взять.

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

впрочем, как я сказал, лично для меня самая важные фичи те, что я на выходе получаю парзер, управляемый «снаружи», а не парзер, который самостоятельно жрёт в три горла, и что у токенов есть деструкторы. кстати, создание нескольких парзеров — тоже удобная штука: никаких глобалов в парзере не используется.

кое-что из вышеперечисленого можно и от бизона получить, конечно, но… не радует.

Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

294. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Crazy Alex (ok) on 23-Окт-13, 04:09 
Хвалятся - авторы lemon его фичами. Что до перечисленного тобой - таки подходы разные. Я всегда нежно любил, когда потребитель сам данные требует - как-то лучше мне такая архитектура на мозг ложится - скормил ему источник данных и забыл, можно этот парсер, скажем, куда-то передать и он там дальше работать будет с тем же источником. Но я ж плюсовыми категориями мыслю, там это удобно, да и глобальных переменных там нет. Вот насчет деструкторов токенов в голову ничего особо не приходит, но вроде и нужды не было. Хотя гляну детальнее - может, правда с ними красивее получается.
Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

297. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 23-Окт-13, 04:20 
> Хвалятся - авторы lemon его фичами.

где? на всякий случай: перечисление != похвальба.

> Я всегда нежно любил, когда потребитель сам данные требует

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

> — как-то лучше мне такая архитектура на мозг ложится — скормил
> ему источник данных и забыл, можно этот парсер, скажем, куда-то передать
> и он там дальше работать будет с тем же источником.

штука в том, что объединить «управляемый» парзер и лексер в одну сущность совсем несложно. а вот «разорвать» лексер и парзер в случае, когда парзер сам всё решает — шибко сложнее.

> может, правда с ними красивее получается.

иногда — красивей. достаточно часто для простых грамматик делать zone allocator лениво, а хранить дополнительную информацию в токене удобно. используем malloc(), при этом не напрягаемся по поводу того, кто и когда позовёт free().

p.s. или мегахаки типа «предпросмотра на токен вперёд и вызова разных парзеров в зависимости от». согласен, это можно и грамматикой сделать. но иногда бывает нужно и вот так — проще получается.

Ответить | Правка | ^ к родителю #294 | Наверх | Cообщить модератору

225. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:30 
>>nft ничем в этом плане не отличается от iptables (кроме отсутствия минусов).
> Докажи.
> Хотя бы на примере из сабжа выше — как проверить валидацию параметров
> до запуска. Формально конечно, не смысл самих правил.

Бизон в помощь, очевидно же.

>>а про дамп правил?
> Во, о чём и речь. Пошли какие-то свои термины, своего (нарождающегося на
> ходу) стантарда, своих правил.…
> Как проверить корректность сформированной командной строки ДО запуска?

Так дампа правил или командной строки?

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

239. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 22-Окт-13, 03:10 
>> Хотя бы на примере из сабжа выше — как проверить валидацию параметров
>> до запуска. Формально конечно, не смысл самих правил.
> Бизон в помощь, очевидно же.

Не стоит слушать вышевыссказавшихся товарищей. Они бизон в сабже увидели и обрадовались.
А тем временем парсер на бизоне используется для трансформации сабжевого синтаксиса во внутреннее представление в самом сабже.
Это понятно?
Мне ТРАНСФОРМИРОВАТЬ ничего и никуда не нужно. Вы ещё xslt посоветуйте, угу.
В общем идиoтский совет.

>>>а про дамп правил?
>> Как проверить корректность сформированной командной строки ДО запуска?
> Так дампа правил или командной строки?

Вы тупoй, извиняюсь? Ответил уже.


Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

243. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 22-Окт-13, 03:30 
зыж

Вот кстати пруф на оригинал 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

И да, предлагать использовать (в дополнение к своей) программу, предназначенную для автоматического создания синтаксических анализаторов, только для того, чтобы проверить валидность командной строки… э-э-э, как бы это помягче то… ОЧЕНЬ оригинально.
Что дальше? Баллистическую ракету при охоте на воробьёв?

Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

280. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 20:59 
> И да, предлагать использовать (в дополнение к своей) программу, предназначенную для автоматического
> создания синтаксических анализаторов, только для того, чтобы проверить валидность командной
> строки… э-э-э, как бы это помягче то… ОЧЕНЬ оригинально.
> Что дальше? Баллистическую ракету при охоте на воробьёв?

А вы для анализа команд iptables предлагаете использовать какие-то дополнительные библиотеки, вместо strcmp. Тоже очень оригинально.

Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

279. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 20:57 
> Мне ТРАНСФОРМИРОВАТЬ ничего и никуда не нужно. Вы ещё xslt посоветуйте, угу.

Тогда срочно выкинь все свои библиотеки для команд POSIX - они тоже по большей части ТРАНСФОРМИРУЮТ.

> Вы тупoй, извиняюсь?

Просите, не мы, а вы.

> Ответил уже.

Вы постоянно перепрыгиваете с дампов на командную строку и обратно. Простите, не какой из этих ответов вы ссылаетесь?

Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

285. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от ананим on 22-Окт-13, 21:13 
Да-а-а, тяжёлый случай.
Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

87. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от www2 (??) on 20-Окт-13, 08:09 
>В силу структуры iptables, невозможно добавить/удалить одно правило, не поменяв весь набор.

Это ты про внутреннюю организацию всего этого хозяйства говоришь или говоришь о том, что из командной строки добавить/удалить одно правило невозможно?

>Правила хранятся в ядре в виде блоба, который формируется утилитами в userspace. При изменении одного правила, его нужно генерировать с нуля.

И тем не менее, одна команда с точки зрения пользователя добавляет/удаляет одно правило.

>Именно поэтому разработчики iptables рекомендуют вместо скриптов с кучей команд iptables использовать iptables-restore (см. Jan Engelhardt, Towards to the perfect ruleset).

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

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

113. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 13:39 
> Это ты про внутреннюю организацию всего этого хозяйства говоришь или говоришь о
> том, что из командной строки добавить/удалить одно правило невозможно?

О внутренней. Пакеты фильтрует netfilter, а не iptables.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

124. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от ананим on 20-Окт-13, 14:52 
При этом в ядре таблицы меняются простой сменой указателей.
Вот, специально не поленился и посмотрел как это работает http://www.opennet.dev/openforum/vsluhforumID3/92256.html#122

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

Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

163. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Гость on 21-Окт-13, 00:24 
>> Синтаксис иптаблес лучше
> Чем грузины? Или чем армяне?

Чем синтаксис pf. Это же любому админу локалхоста сходу понятно.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

136. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:23 
> Иди отсюда, арчеребёнок. Синтаксис иптаблес лучше

Арче-ребенок :))) ? ахахаххахха
Вы уважаемый, его установить то сможете хоть ? пфхазхахахаха.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

42. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 02:55 
> У вас, видимо, браузер не отображает пробелы. Наверное, стоит написать багрепорт разработчикам.

Будьте последовательны. Убрали тире - уберите и пробелы, чтоб читалось быстрее. :))

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

44. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 02:58 
> Будьте последовательны. Убрали тире - уберите и пробелы, чтоб читалось быстрее. :))

Будьте последовательны. Вам нравится, когда слова визуально разделены? Не ограничивайтесь тире и пробелами, разделяйте их как минимум переводами строки.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

137. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:38 
> Будьте последовательны. Вам нравится, когда слова визуально разделены? Не ограничивайтесь
> тире и пробелами, разделяйте их как минимум переводами строки.

Будет Маяковский-style.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

55. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 03:46 
> Будьте последовательны. Убрали тире - уберите и пробелы, чтоб читалось быстрее. :))

-А --ВЕДЬ --верно --говоришь -, --ДРУК -!
-С --ТИРЕ --текст --действительно --читается --гораздо --ЛУЧШЕ -.
--Теперь --БУДУ --всегда --только --так --ПИСАТЬ -.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

56. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 03:49 
-А --СИНТАКСИС --iptables --все --же --надо --ПОПРАВИТЬ -.
--Некоторые --ЛЕКСЕМЫ --там --идут --без --ТИРЕ -.
--Например -, --ИМЕНА --цепочек -, --таблиц -, -а --еще --адреса -и --ПОРТЫ -.
--Это --СИЛЬНО --ухудшает --ЧИТАЕМОСТЬ -.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

64. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от ананим on 20-Окт-13, 04:01 
Зато сильно уменьшает количество возможных ошибок при программирования разбора параметров командной строки.


зыж
А вот это выдаёт вас как профана с головой:
>--Некоторые --ЛЕКСЕМЫ --там --идут --без --ТИРЕ -.
>--Например -, --ИМЕНА --цепочек -

имя цепочки — это аргумент параметра -A, -D, -I,…

С учётом вышесказанного, как бы всё равно удобно профанам читать или нет.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

66. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 04:03 
> имя цепочки — это аргумент параметра -A, -D, -I,…

-В --ЭТОМ -- --то -и --проблема -!
--Аргументы --ВИЗУАЛЬНО --сливаются -с --параметром -, --что --значительно --ухудшает --читаемость --ТЕКСТА -!

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

70. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от ананим on 20-Окт-13, 04:26 
Да, для секретарш не удобно, я ведь уже говорил?
Но для них командная строка не удобна вообще, в силу только своего существования.

Что-то ещё?

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

75. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 04:37 
> Да, для секретарш не удобно, я ведь уже говорил?

--Не --ТОЛЬКО --для --СЕКРЕТАРШ -.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

79. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от ананим on 20-Окт-13, 04:59 
Конечно-конечно.
Есть КУЧА профессий. Бухгалтера например.
Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

65. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 04:01 
> Кому оно напрашивалось? Вот посмотрите на новый синтаксис с точки зрения эргономики
> - все сливается... не хватает разделителей (типа '-')... Трудно читабельно, и
> не похоже на стандартный синтаксис CLI.

--Все --ПРАВИЛЬНО --ГОВОРИШЬ -!
-Я --ПРОСТО --не --понимаю -, --как --раньше --мог --читать --текст --без --тире --перед --каждым --СЛОВОМ -!

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

71. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 04:27 
>-Я --ПРОСТО --не --понимаю -, --как --раньше --мог --читать --текст --без --тире --перед --каждым --СЛОВОМ -!

Э… Может потому что ты не iptables?

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

123. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Michael Shigorin email(ok) on 20-Окт-13, 14:48 
>>-Я --ПРОСТО --не --понимаю
> Э… Может потому что ты не iptables?

Вам точно не надоело ещё?

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

132. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:07 

> получается
> 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 ?

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

27. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 01:50 
Когда они планируют выбросить поддержку iptables?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 01:55 
Никогда?
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

52. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 03:39 
Нет смысла держать дублирующие подсистемы, от одной из них откажутся рано или поздно.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

28. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 01:53 
Синтаксис правил просто фееричен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

34. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Igor (??) on 20-Окт-13, 02:08 
не ну то что они решили сделать чтото лучше это хорошо... только вот за каким лешим делать синтаксис да не сложный и логический но блин сливавшийся в 1 целое в глазах... Лично мне больше нравится старый синтаксис... просто он реально наглядней
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от Аноним (??) on 20-Окт-13, 02:15 
> не ну то что они решили сделать чтото лучше это хорошо... только
> вот за каким лешим делать синтаксис да не сложный и логический
> но блин сливавшийся в 1 целое в глазах... Лично мне больше
> нравится старый синтаксис... просто он реально наглядней

Так вот откуда берутся люди, которые через каждые несколько слов лепят многоточия!
Только сейчас понял :)

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

85. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от анон on 20-Окт-13, 07:42 
смайлофаг закукарекал
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

112. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –3 +/
Сообщение от Аноним (??) on 20-Окт-13, 13:38 
> смайлофаг закукарекал

Да-да))) вот)) таким)))) товарищам)))) новый)) синтаксис)) тоже)))) не) понравится)))))))))))))))))))))))

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

153. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от anonymous (??) on 20-Окт-13, 20:58 
>> смайлофаг закукарекал
> Да-да))) вот)) таким)))) товарищам)))) новый)) синтаксис)) тоже)))) не) понравится)))))))))))))))))))))))

(зато (лисперы оценят))

Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

154. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Michael Shigorin email(ok) on 20-Окт-13, 21:04 
> (зато (лисперы оценят))

Это -- да, бо скобочки в паритете.  А тот безглазый истерический мусор предлагаю вымести.

Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

258. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Адекват (ok) on 22-Окт-13, 13:12 
>> смайлофаг закукарекал
> Да-да))) вот)) таким)))) товарищам)))) новый)) синтаксис)) тоже)))) не) понравится)))))))))))))))))))))))

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

Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

176. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Ordu email(ok) on 21-Окт-13, 03:56 
Видимо это единственный известный автору знак препинания. Вот он и натыкал его побольше, чтобы не подумали, что он безграмотный.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

221. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:20 
> Видимо это единственный известный автору знак препинания. Вот он и натыкал его побольше, чтобы не подумали, что он безграмотный.

Я раньше тоже так думал. А теперь понятно — ему просто нужно «визуально разделять слова»©.

Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

38. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ferux (ok) on 20-Окт-13, 02:19 
интересно вот, планируется ли в нём поддержка фильтрации для заданных исполняемых файлов или их групп. А то 21й век идёт, а нет до сих пор нормальной реализации этого. То, что через SELinux делается - как-то костыльно. AppArmor-цы - обещают ток в 3й версии начать поддерживать подобное.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +2 +/
Сообщение от Igor (??) on 20-Окт-13, 02:25 
эм а с этого места можно поподробней...
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

138. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 16:42 
ну типа разрешил в фаерволе ц:\\свалка програм\\опись\\ворд.exe, запустил… и вирусы полезли.

зыж
хинт:
# mv /usr/bin/proga /usr/bin/proga.orig
# cat > /usr/bin/proga
iptables -A OUTPUT… <разрешаем чё надыть>
<ещё может чё надо>
/usr/bin/proga.orig
Ctrl-D
#
усё, 21 век наступил.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

145. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Michael Shigorin email(ok) on 20-Окт-13, 19:06 
> усё, 21 век наступил.

И шо, +x не надо и от юзера заработает? :)

Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

155. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 21:27 
Ну да, и его тоже.
Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

171. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 21-Окт-13, 01:11 
> хинт:
> # 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

упс.

Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

194. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +2 +/
Сообщение от ананим on 21-Окт-13, 08:27 
А у тебя /usr/bin/true в интернет лазит?!!
Поздравляю.
Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

228. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +1 +/
Сообщение от arisu (ok) on 21-Окт-13, 18:10 
> А у тебя /usr/bin/true в интернет лазит?!!

/usr/bin/proga у меня вообще отсутствует. (пожимает плечами) замени true на wget, разрешаю. посмею тебя удивить: результат не поменяется. всё равно скажет, что прав нет. я понимаю: для тех, кто работает под рутом, это очень удивительно и непривычно. а вам сколько раз повторяли: «не работай под рутом»? вы отчего не слушали умных людей?

Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

247. "В ядре Linux 3.13 ожидается появление нового пакетного..."  –1 +/
Сообщение от ананим on 22-Окт-13, 03:48 
Видишь ли, любой вменяемый админ сразу (практически интуитивно) догадывается, что если речь идёт о файле в /usr/bin, то требуются рутовые права.
В общем то, админ — он и есть рут.
Ну не дали тебе рута, так какие твои годы? И фаервол ты тоже не можешь настроить… ну, пока тебе рута таки не дадут. Так что и тема сабжа пока не для тебя.
Такова селяви.

>а вам сколько раз повторяли: «не работай под рутом»? вы отчего не слушали умных людей?

Ну, это мы именно вам говорили.
И будем говорить.

Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

174. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ferux (ok) on 21-Окт-13, 02:38 
> # 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?

Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

255. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 22-Окт-13, 07:53 
вам поможет (как обычно) документация знание предметной области:
вот база для размышлений:

# 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

Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

272. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ferux (ok) on 22-Окт-13, 19:30 
> # 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. эту проблему и решат, но всё же).

Правильный подход к конфигурированию подсистемы, это когда для изменения одного из её параметров (например, запрета отправки пакета на заданный порт для заданного приложения) нужно  добавить опцию только в одном месте.

Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

273. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 19:42 
> Да, это не костыльная система, запускать все приложения от отдельного пользователя…

прикинь: не костыльная. тут ссылка проскакивала на 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 в том, что они тупо добавляют новую сущность вместо использования старых там, где это вполне вписывается в логику.

Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

275. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от ferux (ok) on 22-Окт-13, 20:08 
> ага. а тут мне вдруг захотелось странного: вот сейчас этой программе доступ
> дать (на один запуск). а вот той — не давать (на
> один запуск).
> ...а что я делаю, если «всё в одном месте»?

так кто сказал, что нужно "iptables -m owner --uid-owner..." отменить?
Я за то, что нужно сюда же добавить возможность задания что-то вроде "iptables -m path /path/to/bin ...". В таком случае для реализации упомянутого "странного" желания можно так же задать пользователей, которым можно для данного приложения иметь доступ, и которым нельзя, используя "-m owner" совместно с "-m path".

Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

277. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 20:52 
> Я за то, что нужно сюда же добавить возможность задания что-то вроде
> «iptables -m path /path/to/bin …».

«это было-было-было, но прошло» (ц) был cmd-owner, но работало, говорят, фигово и вообще как-то лишним торчало.

ну и да: это уже скорее задача user-mode firewall. я PoC делал (да и не только я, думаю) — для динамически слинкованых софтин, которые не дёргают ядро напрямую, конечно. особо большой пользы в этом не увидел, честно говоря, равно как и в моих примерах выше.

не знаю, как-то оказалось, что вполне хватает разделения по пользователям/группам. мне, честно говоря, лень сейчас искать, почему точно cmd-owner выкинули. может, кто неленивый за меня найдёт и ссылки сюда кинет.

Ответить | Правка | ^ к родителю #275 | Наверх | Cообщить модератору

274. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Michael Shigorin email(ok) on 22-Окт-13, 19:59 
> вот база для размышлений:

IMNSHO для такого уже становятся удобней контейнеры, поскольку изолирование на ФС с изолированием по сети ходят под ручку.

Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

227. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:35 
> ну типа разрешил в фаерволе ц:\\свалка програм\\опись\\ворд.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" в старых редхатах

Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

73. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 20-Окт-13, 04:36 
Я то же мечтать, хотеть быть правила на бинарник!
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

165. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Гость on 21-Окт-13, 00:30 
> интересно вот, планируется ли в нём поддержка фильтрации для заданных исполняемых файлов
> или их групп. А то 21й век идёт, а нет до
> сих пор нормальной реализации этого. То, что через SELinux делается -
> как-то костыльно. AppArmor-цы - обещают ток в 3й версии начать поддерживать
> подобное.

Ожидайте, в следующую итерацию в Линукс украдут и ipfw.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

172. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +4 +/
Сообщение от arisu (ok) on 21-Окт-13, 01:12 
> украдут и ipfw.

и как же bsd будет без ipfw тогда?

Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

216. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 21-Окт-13, 16:08 
> Ожидайте, в следующую итерацию в Линукс украдут и ipfw.

А зачем Линуксу фаервол, имеющий проблемы с производительностью и масштабируемостью?

Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

265. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от anonymousZ on 22-Окт-13, 17:07 

Самым первым фаерволом и linux и был  ipfwadm, фактически переписанный ipfw.
Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

40. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от commiethebeastie (ok) on 20-Окт-13, 02:48 
Наконец-то можно закопать кучу костылей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 02:58 
Копалка пока ещё пока не отросла.
Лихорадочно искал в новости строки:
>Представленный для ядра 3.13 код предусматривает сосуществование старой и новой подсистем, так как Nftables ещё требует доработки и тестирования.

А то пришлось бы повременить с ядрами >=3.13.
Нет желания переписывать 100500 правил.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

48. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от _KUL (ok) on 20-Окт-13, 03:13 
как раз у страуструпа начал читать про парсер с++ и там пример в книге, как раз про такой синтаксис. ну очень он не удобный, нежели линейные правила.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

80. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 05:05 
Читать ещё пол-беды.
А вот сформировать, потом ещё и проверить валидность (до факапа при самом уже выполнении) сложнее.
Не говоря о том, что это фактически свой собственный язык разметки, который тоже нужно будет знать.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

81. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от mma on 20-Окт-13, 06:11 
Посмотрим, довольно интересно, человеческий набор правил радует.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

82. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 06:29 
Ну наконец то вливают наработки, эпохальное событие года 2 ждем уже.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

90. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Ограбитель Корованов on 20-Окт-13, 09:04 
>Ну наконец то вливают наработки, эпохальное событие года джва ждем уже.

//исправил, не благодари

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

88. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от www2 (??) on 20-Окт-13, 08:19 
>table filter hook input priority 0;

Точка с запятой в конце - обязательны? Чем объясняется, что в дальнейших правилах её нет?

>ct state established accept
>ct state related accept

А как раньше ct state established,related accept уже нельзя?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Окт-13, 09:17 
Точка с запятой в конце - обязательны? Чем объясняется, что в дальнейших правилах её нет?

C синтаксис xD

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

222. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:21 
> А как раньше ct state established,related accept уже нельзя?

Да пожалуйста: ct state {established, related}

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

117. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от ALex_hha (ok) on 20-Окт-13, 14:04 
Это из оперы - "Чем грузины лучше" ;)


# 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

второе правилу ну никак не наглядней, хоть с какой стороны на него смотреть

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

119. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Andrey Mitrofanov on 20-Окт-13, 14:07 
> # 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 Глаза смотрящего точно.

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

125. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от miha (??) on 20-Окт-13, 15:19 
>[оверквотинг удален]
> # 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 -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

???

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

133. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 16:12 
хуже, когда будет так:
# nft daddr 1.2.3.4 ip tcp add ip rule filter dport output 80 drop
и сразу в глаза не бросается, т.к. не понятно где параметр, а где его атрибут.
Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

218. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:16 
> # nft daddr 1.2.3.4 ip tcp add rule ip filter output dport 80 drop

Нет, это не заработает. daddr и saddr - уточняющие субселекторы селектора ip. А dport - уточняющий параметр субселектора tcp. И т.д.
Синтаксис nft подчиняется правилам, алогичным человеческой речи. А в ней тоже нельзя произвольно смешивать слова.

Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

233. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 02:10 
И ничему-то их SQL не научил... Тоже пытались сделать a-la человеческая речь.
Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

237. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +1 +/
Сообщение от arisu (ok) on 22-Окт-13, 02:19 
> И ничему-то их SQL не научил… Тоже пытались сделать a-la человеческая речь.

и верно. то ли дело какое-нибудь @#%^%@#%. или вон как у sendmail — образец удобства и понятности.

Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

261. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 13:26 
Ну так переборщить что угодно можно. Не пойму, чем тебя так смущает желание видеть явные отличия имен параметров от значений?
Ответить | Правка | ^ к родителю #237 | Наверх | Cообщить модератору

264. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от ананим on 22-Окт-13, 15:45 
человек не понимает разницу между параметрами программы и фронт-эндом по настройке этих параметров.

зыж
штоб править ему всю жизнь его виндовый (и бинарный) реестр хекс-эдитором! :D

Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

270. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 18:39 
> Ну так переборщить что угодно можно. Не пойму, чем тебя так смущает
> желание видеть явные отличия имен параметров от значений?

потому что это совсем не обязательно при правильном построении грамматики. ты же не ставишь, например, дефис перед глаголами, снежинку перед прилагательными и плюс перед существительными? тем не менее, грамотно составленые предложения вполне читаются. без лишнего визуального мусора.

Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

289. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от ананим on 22-Окт-13, 21:28 
1. Абзацы, оглавления и т.д. не от хорошей жизни придумали.
2. Даже в белитристике сплошным текстом не пишут.
3. Фронт-энды удобством для пользователей должны заниматься.
Ответить | Правка | ^ к родителю #270 | Наверх | Cообщить модератору

295. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Crazy Alex (ok) on 23-Окт-13, 04:10 
Ну ты сравнил. Сколько усилий надо приложить, чтобы естественным языком овладеть?
Ответить | Правка | ^ к родителю #270 | Наверх | Cообщить модератору

296. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 23-Окт-13, 04:13 
> Ну ты сравнил. Сколько усилий надо приложить, чтобы естественным языком овладеть?

я не сравнил, я намекнул, что даже несоизмеримо более сложные грамматики обходятся почти без лишней фигни.

Ответить | Правка | ^ к родителю #295 | Наверх | Cообщить модератору

281. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 21:03 
> Ну так переборщить что угодно можно. Не пойму, чем тебя так смущает
> желание видеть явные отличия имен параметров от значений?

Потому что эти "ясные" отличия де-факто являются визуальным мусором и только ухудшают читабельность.
В нормальной человеческой грамматике (например, русской и английской) их нет, что не мешает нам общаться.

Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

293. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от ананим on 23-Окт-13, 00:43 
В вашем комментарии есть и ".", и ",", и "(", и """, и "-".
Так что не нужно "заливать" про "визуальный мусор".
Мусор — это когда текст идёт "сплошняком", как в сабже. Где не понятно где параметр, а где его атрибут. И быстро вычленить в большом объёме правил это точно визуально не получиться.
Ответить | Правка | ^ к родителю #281 | Наверх | Cообщить модератору

282. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 21:05 
> И ничему-то их SQL не научил... Тоже пытались сделать a-la человеческая речь.

Ну расскажите нам о проблемах тысяч админов из-за синтаксиса (именно синтаксиса, а не архитектуры или внутренней реализации) pf и ipfw.

Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

129. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от commiethebeastie (ok) on 20-Окт-13, 16:04 
Когда будет этих правил пару тысяч, тогда поймете разницу.
Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

135. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от ананим on 20-Окт-13, 16:15 
это точно.
тогда выделение атрибутов от их параметров играет не малую роль.
Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

134. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Адекват (ok) on 20-Окт-13, 16:13 
>[оверквотинг удален]
> # 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 ?

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

143. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от Аноним (??) on 20-Окт-13, 18:32 
>>[оверквотинг удален]
> Как будет на языке 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, и это печально, что молодые горячие программисты ну никак не хотят учитывать опыт хождения по граблям старших коллег, им обязательно нужно самим получить по голове для остроты ощущений :(

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

167. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Гость on 21-Окт-13, 00:35 
> "dport" etc). В случае же nft придется подбирать названия цепочек специально

Я вас умоляю, сделаете темплейты. Можно подумать серьезная конфигурация iptable без них обходится.

Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

224. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 21-Окт-13, 16:27 
> НО! То, что аргументы и параметры сливаются в одну кучу, никаким образом
> между собой ни визуально, ни логически не различимы - это очень
> плохо. Например, в случае синтаксиса iptables я спокойно могу называть цепочку
> любым нужным мне для словом (напр. "tcp", "udp", "ip", "rule", "add",
> "dport" etc). В случае же nft придется подбирать названия цепочек специально,
> чтобы они не пересекались с названиями параметров

С чего вы взяли? Такое ограничение пришлось бы вводить только в случае разрешенного хаотического перемешивания параметров и аргументов. Но оно же не разрешено.

Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

146. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Igor (??) on 20-Окт-13, 19:07 
походу вот так
nft add rule ip filter output ip saddr 1.2.3.4 tcp dport
Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

151. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от raven_kg (ok) on 20-Окт-13, 20:22 
Хмм... Поцтерингом попахивает!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

152. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +4 +/
Сообщение от Inome email(ok) on 20-Окт-13, 20:49 
Какие дебильные и длинные цепочки правил... Нет, чтобы доработать существующий iptables, они начинают пилить новый, ему замену с более убогим и неудобным синтаксисом, это пять!..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

173. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +1 +/
Сообщение от arisu (ok) on 21-Окт-13, 01:15 
правила чем-то ferm напоминают.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

175. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +3 +/
Сообщение от 3draven (ok) on 21-Окт-13, 03:12 
Вообще, не знаю есть ли такое, но хотелось бы видеть что то вроде функционального языка программирования фаервола. Что бы ты написал

main(packet){
if(packet.port == 80 && packet.elf = "myrestrictedelfprogram"){
return null;
}

}

Транслятор это дело в байткод прокинул и отправил я ядро. Судя по всему от этого нового нетфильтра до идеи парсить произвольный код в байткод фильтра, рукой подать. Что то типа llvm для пакетного фильтра, где фронтенд на произвольном языке, бекенд на байткоде. Что бы правила были совсем гибкими, честно сказать не люблю идею таблиц как таковую.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

177. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от VolanD (ok) on 21-Окт-13, 06:20 
> Вообще, не знаю есть ли такое, но хотелось бы видеть что то
> вроде функционального языка программирования фаервола. Что бы ты написал
> main(packet){
> if(packet.port == 80 && packet.elf = "myrestrictedelfprogram"){
> return null;
> }
> }

Много букаф слишком, нет?


Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

179. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 07:17 
Ну дак for, switch, while в руки и вперед. Просто взять скриптовый язык и прикрутить бекендом фаервол работающий с байткодом. Написать сотню правил и генератор правил к ним сложнее чем написать один цикл. Должно быть наоборот меньше букаф, да к тому же намного читабельнее, что немаловажно.

А сколько туда накрутить таким методом можно всяких других фич, которые к таблицам ни боком ни раком, даже предположить трудно.

Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

182. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от VolanD (ok) on 21-Окт-13, 07:26 
> Ну дак for, switch, while в руки и вперед. Просто взять скриптовый
> язык и прикрутить бекендом фаервол работающий с байткодом. Написать сотню правил
> и генератор правил к ним сложнее чем написать один цикл. Должно
> быть наоборот меньше букаф, да к тому же намного читабельнее, что
> немаловажно.
> А сколько туда накрутить таким методом можно всяких других фич, которые к
> таблицам ни боком ни раком, даже предположить трудно.

Так то канеш красиво получается и не надо читать кучу манов, если синтаксис СИ-подобный. Но с другой стороны простейшие правила: permit host 192.168.0.1 потребуют больше текста. Мне кажется было бы классно совместить оба варианта.

Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

184. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 07:31 
Ну, текущую инфраструктуру все равно оставить можно, конечно, она живая и никому не мешает. Вот только мои тут "идеи" все равно разрабы ядра не слышат :) Между тем в других системах lua потихоньку встраивают...прогресс идет, пока прохожие плеваются :)
Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

187. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 07:41 
Главное, это дает резкое упрощение разработки для ядра, прототипирования, да и просто универсалный интерфейс к системам ядра. Меньше манов. Отсюда, думаю, взрывной рост разработки для ядра на скрипте, а потом перенос в С/С++ готовых продуктов для продакшена. В общем со всех сторон польза. Причем даже обычный юзер вроде меня сможет поковырять разработку для ядра на досуге.
Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

188. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от VolanD (ok) on 21-Окт-13, 07:59 
> Главное, это дает резкое упрощение разработки для ядра, прототипирования, да и просто
> универсалный интерфейс к системам ядра. Меньше манов. Отсюда, думаю, взрывной рост
> разработки для ядра на скрипте, а потом перенос в С/С++ готовых
> продуктов для продакшена. В общем со всех сторон польза. Причем даже
> обычный юзер вроде меня сможет поковырять разработку для ядра на досуге.

Кстати да, всякие DPI легче разрабатывать, наверное )

Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

189. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 08:04 
Шутки у вас :)


Но, сейчас документация на системы и конфиги систем ядра, огромна, а универсальный интерфейс по типу этого, ее резко уменьшит, что по моему приятно. Хоть не придется учить бесконечные новые синтаксиы конфигов нетфильтра.

Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

190. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 08:07 
Ведь как ни крути, а любому нетфильтру оперировать типом-классом packet, так что и синтаксис будет одинаков, что для одного нетфильтра, что для другого, в рамках такого скрипта. Отсюда уменьшение бесконечной головной боли. Так же и для других систем. В общем скрипты потому и придумали :)
Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

191. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от pavel_simple (ok) on 21-Окт-13, 08:19 
> Ведь как ни крути, а любому нетфильтру оперировать типом-классом packet, так что
> и синтаксис будет одинаков, что для одного нетфильтра, что для другого,
> в рамках такого скрипта. Отсюда уменьшение бесконечной головной боли. Так же
> и для других систем. В общем скрипты потому и придумали :)

java головного мозгу, вам термин overengineering поди не знаком?

Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

200. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 13:15 
Ну вы там это, учите новые правила нетфильтра, флаг в руки :) А потом снова и снова, это особый кайф я погляжу и никакого овер, да.
Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

202. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 13:28 
Унификация средств конфигурирования и простого расширения подсистем ядра отделит мечтательные мозги разрабов очередного нетфильтра от стандарта конфигурирования. Что даст возможность конфигурить любой сервис одним средством и создавать собственные сервисы поверх нескольких сервисов ядра. По моему удобно.
Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

204. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 13:52 
http://www.netbsd.org/gallery/presentations/mbalmer/fosdem20...
Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

180. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 07:19 
сложнейшую маршрутизацию и прочее все туда же. А сервисы ядра подключать как библиотеки языка. Типа если надо конфигурять нетфильтр, такая либа, если надо еще что то, такая. Унифицированный подход имеем таким образом.
Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

183. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от 3draven (ok) on 21-Окт-13, 07:27 
Причем так как язык очень высокоуровневый надо, то выделений памяти, буферов и прочей муйни, нету. Подключив "либу" к проекту скриптового конфига ты подключаешь входной поток данных (пакеты для нетфильтра например) и встраиваешь проект в инфраструктуру подключенной "либы", то есть она начинает слушать твой выходной поток данных. Так что минимум лишних телодвижений. Потом байткод попадает в ядро и пашет как отдельный кусок конфигуряемой системы.

Потом добавить туда JIT коНпелятор  и счастье наступило :)

Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

195. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от ананим on 21-Окт-13, 08:34 
>А сервисы ядра подключать как библиотеки языка. Типа если надо конфигурять нетфильтр, такая либа,

Не поверишь.
Называются модули ядра.

Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

201. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от 3draven (ok) on 21-Окт-13, 13:24 
Подключать не к ядру, а к скрипту.
Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

178. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +4 +/
Сообщение от Mr. Sneer on 21-Окт-13, 07:06 
Когда коту делать нечего, он яйца лижет, а программисты разрабатывают принципиально новый wayland/gnome3/systemd/nftables/gtk3/clang и т.д.

И в каждой такой новости мы видим рассказы, как предшественник устарел, плох, не безопасен и т.д. Ужас да и только. И как только линукс взлетел со всем этим?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

197. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от const86 (ok) on 21-Окт-13, 11:38 
> И как только линукс взлетел со всем этим?

Дык 1% же, невысоко взлетел. Оказывается, это было из-за устаревшего iptables, но теперь-то жизнь наладится!

Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

198. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Mr. Sneer on 21-Окт-13, 12:00 
Рано ей налаживаться - вот впилят в каждый дистрибутив wayland(мы ведь все знаем, что в X11 даже не один фатальный недостаток нашли, а тысячи их!) в дополнение к systemd, вот тут-то и нагрянет вендокаец, а линукс захватит все 146%!
Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

309. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Янв-14, 20:40 
> вот тут-то и нагрянет вендокаец, а линукс захватит все 146%!

Судя по тому как интел въе над линуксом начал - это не просто так.

Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

308. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 20-Янв-14, 20:39 
> Дык 1% же, невысоко взлетел.

Ну да, а вон те 50% серверов, 50% планшеток, 80% смартов, 90% суперкомпьютеров, почти 100% роутеров и прочей умной электроники мы проигнорируем. Ведь неудобно же замечать такие факты.

Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

203. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от evilman on 21-Окт-13, 13:43 
Для всех хейтеров на заметку: для nftables подготовлена прослойка, которая полностью совместима с ip/ip6/arp/eb tables на уровне синтаксиса команд и интерфейса extensions. Т.о. можно не переучиваться. Во-вторых, все эти ваши экстеншены можно использовать из-под nftables без переделки. Ну и плюс новые плюшки, типа уже встроенных таблиц для хранения наборов данных, маппинга (а-ля tablearg), более дружелюбный к СМП "движок" с минимумом локов, избавление от ненужных дёрганий (не используете хук, так и система не будет проверять пустую цепочку), ну и по мелочи. Концептуально всё это очень похоже на ОпенБСДшный NPF, который чуть позже вышел, но был быстрее интегрирован в систему. Как-то так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

231. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Имярек on 21-Окт-13, 22:54 
Только он не в ОпенБСД, а в НетБСД: http://www.netbsd.org/~rmind/npf/

И действительно, они как близнецы-братья.

Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

234. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 02:16 
Да сама фишка хорошая, синтаксис безумный. Правила ж не надо читать, их надо сканировать, быстро разбирая на составные части. Синтаксис iptables это отлично даёт со своими минусами. А здесь - глазу зацепиться не за что. То есть там нужно тебе -s - ты его и ищешь, и сразу видишь. А sport среди других слов не выделяется никак.
Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

238. "В ядре Linux 3.13 ожидается появление нового пакетного..."  –1 +/
Сообщение от arisu (ok) on 22-Окт-13, 02:20 
> Правила ж не надо читать, их надо сканировать, быстро разбирая на составные части.

слушай, переложи уже работу фильтрации пакетов на машину. ну трудно же тебе каждый пакет ручками обрабатывать, упорно читая правила. надорвёшься.

Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

253. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +1 +/
Сообщение от ананим on 22-Окт-13, 05:09 
для идиoтиков, тут про фильтрацию правил, а не пакетов.
переложить это можно только на более компетентного админа. в твоём — случае практически на любого другого человека. но не на машину.
Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

254. "В ядре Linux 3.13 ожидается появление нового пакетного..."  –1 +/
Сообщение от arisu (ok) on 22-Окт-13, 05:29 
о, ещё один представитель племени пишущих правила в бессознательном состоянии. сначала оно сидит на винде и ставит варез из помоек, потом перелазит на бубунту и… всё равно ставит варез из помоек. и думает, что проблему его безмозглости можно решить программно.
Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

263. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от ананим on 22-Окт-13, 15:39 
эт точно! :D
arizu one:
>слушай, переложи уже работу фильтрации пакетов на машину.

arizu two:
>и думает, что проблему его безмозглости можно решить программно.

да, вот так вы и живёте. хорошо хоть признаёшь свою ущербность. :D
а нам вот всё самим да самим правила писать приходится.

Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

257. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Crazy Alex (ok) on 22-Окт-13, 13:10 
Хочешь сказать, что никогда пачку правил не смотрел глазами чтобы понять, что там подправить надо?
Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

266. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 18:18 
> Хочешь сказать, что никогда пачку правил не смотрел глазами чтобы понять, что
> там подправить надо?

хочу сказать, что рапарзивать «$#%$^@^» шибко сложнее, чем слова: я именно поэтому и взял ferm. и здесь я вижу правила, похожие на ferm'овые. читаются без проблем. в отличие от однобуквенных аргументов.

мозг вообще читает фразы, составленые из слов, намного лучше, чем фразы, составленые из букв и закорючек. кто не верит — может попробовать прочесть какое-нибудь длинное регулярное выражение.

Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

301. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +1 +/
Сообщение от Crazy Alex (ok) on 23-Окт-13, 11:41 
Ну так речь же не о том, чтобы сплошные значки были. Но вот эти sport/dport явно менее заметны, чем -s/-d. И -j, опять же, позволяет быстрее понять, где начинается rule target, если он с параметром (если без - тупо читаем последнее слово, конечно).

Короче, ладно, разница в восприятии.

Ответить | Правка | ^ к родителю #266 | Наверх | Cообщить модератору

302. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 23-Окт-13, 18:20 
> вот эти sport/dport явно менее заметны, чем -s/-d

Прочтя в черноморской вечерке объявление «Сд. пр. ком. в уд. в. н. м. од. ин. хол.» и мигом сообразив, что объявление это означает — «Сдается прекрасная комната со всеми удобствами и видом на море одинокому интеллигентному холостяку»…

Ответить | Правка | ^ к родителю #301 | Наверх | Cообщить модератору

287. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Аноним (??) on 22-Окт-13, 21:16 
> Да сама фишка хорошая, синтаксис безумный. Правила ж не надо читать, их
> надо сканировать, быстро разбирая на составные части. Синтаксис iptables это отлично
> даёт со своими минусами. А здесь - глазу зацепиться не за
> что. То есть там нужно тебе -s - ты его и
> ищешь, и сразу видишь. А sport среди других слов не выделяется
> никак.

Синтаксис вашей речи не позволяет ее парсить, извините.
Пожалуйста, ставьте минусы перед каждым словом.

Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

300. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Crazy Alex (ok) on 23-Окт-13, 11:36 
Еще один. Разницу между атрибутом и параметром понимаем? Hint: почему в SQL принято ключевые слова писать большими буквами, а имена полей/таблиц - малыми?
Ответить | Правка | ^ к родителю #287 | Наверх | Cообщить модератору

305. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от pavlinux (ok) on 27-Окт-13, 00:04 
> Еще один. Разницу между атрибутом и параметром понимаем? Hint: почему в SQL
> принято ключевые слова писать большими буквами, а имена полей/таблиц - малыми?

Наследие IBM System/360 и VAX/VMS, Фортранщеги ваще капслок гвоздём прибивают.

Ответить | Правка | ^ к родителю #300 | Наверх | Cообщить модератору

205. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Аноним (??) on 21-Окт-13, 14:01 
взаимоинтеграция
линукс на бздю и наоборот
дополнительный фактор развития
когда количество сущностей увеличивается, это не всегда баг системы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

206. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –1 +/
Сообщение от Аноним (??) on 21-Окт-13, 15:29 
Документация представлена в виде коротко "How to" ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

215. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от V (??) on 21-Окт-13, 16:04 
вот и переписали ferm на C
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

219. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  –2 +/
Сообщение от Аноним (??) on 21-Окт-13, 16:17 
не то, чтобы это тянет на файрвол, но хоть какая-то движуха, изменения/инновации.
но увы, для усложнения байпаса файрвола - прийдется сторонние "костыли" юзать вроде Zorp. два почти доведенных до ума, надежных файрвола - отпинали из Линукс, уже, к сожалению. а netfilter/iptables больше на анекдот похож. в роутере нормально(иногда;) а вот узлы и бордеры требуют мало-мальски, защиты, однако )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

256. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от commiethebeastie (ok) on 22-Окт-13, 12:59 
> не то, чтобы это тянет на файрвол, но хоть какая-то движуха, изменения/инновации.
> но увы, для усложнения байпаса файрвола - прийдется сторонние "костыли" юзать вроде
> Zorp. два почти доведенных до ума, надежных файрвола - отпинали из
> Линукс, уже, к сожалению. а netfilter/iptables больше на анекдот похож. в
> роутере нормально(иногда;) а вот узлы и бордеры требуют мало-мальски, защиты, однако
> )

Ниасилил? А как должен выглядеть фаерволл? Выскакивать окошко и раздаваться звук раздавленной крысы?

Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

271. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от arisu (ok) on 22-Окт-13, 18:41 
DPI ему не хватает. начальство, видимо, приказало.
Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

307. "В ядре Linux 3.13 ожидается появление нового пакетного..."  +/
Сообщение от Аноним (??) on 20-Янв-14, 20:37 
> DPI ему не хватает. начальство, видимо, приказало.

Тогда ему не хватает не DPI а мозгов и квалификации.

Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

291. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Аноним (??) on 22-Окт-13, 22:04 
>> не то, чтобы это тянет на файрвол, но хоть какая-то движуха, изменения/инновации.
>> но увы, для усложнения байпаса файрвола - прийдется сторонние "костыли" юзать вроде
>> Zorp. два почти доведенных до ума, надежных файрвола - отпинали из
>> Линукс, уже, к сожалению. а netfilter/iptables больше на анекдот похож. в
>> роутере нормально(иногда;) а вот узлы и бордеры требуют мало-мальски, защиты, однако
>> )
> Ниасилил? А как должен выглядеть фаерволл? Выскакивать окошко и раздаваться звук раздавленной
> крысы?

не позволять себя обходить, для начала. ну а в идеале - написаным головой а не ж.
в крайнем случае - руками :)

p.s.
про "выскакивать и звук крысы" порадовало, спасибо. напомнило один смешной продукт на оффтопике от Касперского )

Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

298. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от commiethebeastie (ok) on 23-Окт-13, 08:52 
> не позволять себя обходить, для начала.

https://bugzilla.netfilter.org/


Ответить | Правка | ^ к родителю #291 | Наверх | Cообщить модератору

303. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +1 +/
Сообщение от ваноним on 24-Окт-13, 04:08 
> конечного автомата (pseudo-state machine)

точно не finite state machine?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

306. "В ядре Linux 3.13 ожидается появление нового пакетного фильт..."  +/
Сообщение от Сталин on 09-Ноя-13, 04:55 
Тут установка https://home.regit.org/netfilter-en/nftables-quick-howto/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру