The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обсуждение пакетных фильтров, opennews (??), 26-Июн-07, (0) [смотреть все]

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


11. "Вышел iptables 1.3.8"  +/
Сообщение от Аноним (-), 26-Июн-07, 10:33 
http://www.openbsd.org/faq/pf/ftp.html
Ответить | Правка | Наверх | Cообщить модератору

20. "Вышел iptables 1.3.8"  +/
Сообщение от _Nick_email (??), 26-Июн-07, 11:31 
>http://www.openbsd.org/faq/pf/ftp.html

суперсистема....

"This process acts to "guide" your FTP traffic through the NAT gateway/firewall, by actively adding needed rules to PF system and removing them when done, by means of the PF anchors system."

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

ну, че, в принципе да :) типа можн оразрулить такую ситуевину.
Ну а если чуть усложнить.... и взять не FTP, а допустим ICMP ошибку связанную с запросом TCP коннекта наружу? или даже Quake протокол %))

..сурова жизть бздшников...

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

31. "Вышел iptables 1.3.8"  +/
Сообщение от northbear (??), 26-Июн-07, 13:54 
Ваш сарказм явно не в тему. :))

FTP - откровенно устаревший протокол, созданный во времена, когда про безопасность никто даже не помышлял. И файрволы - это были диковинные программули, создающие проблемы для других.
Совершенно очевидно, что Active Mode FTP мало совместимо с ЛЮБЫМИ файрволами.

И в iptables тоже, чтобы работать с AM FTP необходимо грузить дополнительный модуль (тот же самый по сути ftp-proxy), который жестко завязывается на функционал ядра. Из-за этого портирование iptables с полным Linux'овым функционалом на другие ОС практически не возможно. И говорить, что iptables без проблем работает c такими FTP-соединениями вряд ли можно. Проблемы там есть.

Разработчики же PF просто не стали изобретать велосипед, и сориентировались на готовый  сторонний продукт. И что?

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

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

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

С уважением...

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

46. "Вышел iptables 1.3.8"  +/
Сообщение от _Nick_email (??), 26-Июн-07, 16:21 
>Ваш сарказм явно не в тему. :))
возможно
Люблю обсуждать проблемы неЛинукса ;)
Эдакая война не на своей территории :)


>FTP - откровенно устаревший протокол, созданный во времена, когда про безопасность никто
>даже не помышлял. И файрволы - это были диковинные программули, создающие
>проблемы для других.
ГЫЫЫЫ
первая мысль по поводу: "у меня не работает (плохо работает) - значит никому не надо (устарело)"
вторая мысль: "маркетолог негросовта: М%я! Вы все еще используете протокол, созданный больше 20 лет назад!?? Но с нашим совтом он работает... неоптимально. Да весь мир проноситься мимо вас! Вас нужно срочно переходить на xxxxxx!! Вам даже повезло! В этот день мы вам предоставим скидку!..."

Другими словами: ты шутишь чтоли? Цель: передать файл(ы) с поддержкой авторизации;
максимально эффективно используя канал.
FTP всему этому удовлетворяет.
И если эти выпады в сторону FTP не лишь метод оправдать бзд фаервол - то плз в студию чего такого не умеет FTP, что есть весьма важным на сегодня.


>Совершенно очевидно, что Active Mode FTP мало совместимо с ЛЮБЫМИ файрволами.
Ну сказал - просто убил :)
iptables - это тоже любой файервол, но как видишь он весьма с ним совместим.

>И в iptables тоже, чтобы работать с AM FTP необходимо грузить дополнительный
>модуль (тот же самый по сути ftp-proxy),
чтобы программно решать любую задачу - нужно как минимум загружать код для обработки этой задачи. Т.е.: 1 == 1
Ты еще зачитай что винты вот такие плохие, чтоб с ними работать нужно загружать специальный драйвер...
Пытаясь облить грязью iptables ты обвиняешь байт в том, что он состоит из битов...


>который жестко завязывается на функционал ядра.
"ах вот какой iptables плохой! Он завязан на API ядра Линукс!"
А много драйверов из бзд не "завязано" на функционал бзд ядра? %)))
Т.е. опять же: обвиняешь драйвер ядра в том, что он не совместим с другой ОС/API.


>Из-за этого портирование iptables с полным Linux'овым функционалом на
>другие ОС практически не возможно.
Может будешь удивлен, но он пишеться _для_ Линукса. Это фаервол Линукса.
Его портирование куда-то на другое едро не в сфере интересов девелоперов.
Даже стремление следовать POSIXу сюда приплетать не нужно - это стандарт совместимости _приложений_ с ядром/ОСью. Столь популярных стандартов структуры ядра нет.
Так что его невозможность портирования куда-нить еще - проблема лишь этих "куда-нить еще"


>И говорить, что iptables без проблем
>работает c такими FTP-соединениями вряд ли можно. Проблемы там есть.
УРЛы на нерешенные проблемы поддержки FTP ваерволом iptables, плз.


>Разработчики же PF просто не стали изобретать велосипед, и сориентировались на готовый
>сторонний продукт. И что?
с одной стороны правильно, с другой какой-то папа карло не изобретает велосипед,
а покупает венду...   как по мне - так спорное решение...


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


>Но нет, все равно появится кто-нибудь, кто начнет сравнивать п.пу с п.сей.
У этих органов разные задачи (пусть даже какую-то часть из них можно очертить "опражнением").
Но сказать, что у фаерволов разные задачи.... то это... ЫЫ а как это???


>Если вам, несчастному, приходится работать со столь устаревшими технологиями как AM FTP,
>то мы можем вам только посочувствовать.
Приходиться. И passive и active. Выполненная за глаза задача - чем не основание для использования?
Но пожалейте лучше себя - продолжать врать себе, что линукс не лучше бзд и даже не
пытаться определить истину...  это жалко (особенно второе, конечно же)

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

64. "Вышел iptables 1.3.8"  +/
Сообщение от northbear (??), 26-Июн-07, 21:42 
>ГЫЫЫЫ
>первая мысль по поводу: "у меня не работает (плохо работает) - значит
>никому не надо (устарело)"
>вторая мысль: "маркетолог негросовта: М%я! Вы все еще используете протокол, созданный больше
>20 лет назад!?? Но с нашим совтом он работает... неоптимально. Да
>весь мир проноситься мимо вас! Вас нужно срочно переходить на xxxxxx!!
>Вам даже повезло! В этот день мы вам предоставим скидку!..."

Да причем тут Микрософт? К чему ты его сюда приплел? С чем именно ты не согласен в моем утверждении? C тем, что FTP это устаревший протокол?
Если не вдаваться в holy wars, а просто подумать, то согласись, что использовать два сокета для банальной передачи файла это напрасная трата ресурсов.

В свое время это было сделано только в следствии несовершенства АPI стека TCP/IP и дифицита оперативной памяти систем.
На разных машинах могли быть разные кодировки и данные по символьному каналу она тупо преобразовывалась в рабочую кодировку локальной машины
(она могла быть необязательно ASCII), а по бинарному каналу передавались как есть.
Программы-клиенты получались весьма компактные без лишних заморочек и это было тогда основным достоинством протокола.  

>Другими словами: ты шутишь чтоли? Цель: передать файл(ы) с поддержкой авторизации;
>максимально эффективно используя канал.

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

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

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

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

>
>>Совершенно очевидно, что Active Mode FTP мало совместимо с ЛЮБЫМИ файрволами.
>Ну сказал - просто убил :)
>iptables - это тоже любой файервол, но как видишь он весьма с
>ним совместим.

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

>Пытаясь облить грязью iptables ты обвиняешь байт в том, что он состоит
>из битов...

В каком месте я обливал _грязью_ iptables? Ты бы не заговаривался...

>"ах вот какой iptables плохой! Он завязан на API ядра Линукс!"

Это плод твоей буйной фантазии...

>А много драйверов из бзд не "завязано" на функционал бзд ядра? %)))
>Т.е. опять же: обвиняешь драйвер ядра в том, что он не совместим
>с другой ОС/API.

Одно дело драйвера, а другое дело поддержка рядового, примитивного протокола.

>Так что его невозможность портирования куда-нить еще - проблема лишь этих "куда-нить
>еще"
>
Нет. Это проблема популяризации и широты использования этого продукта.
На FreeBSD, если я правильно помню, iptables не поддерживает ftр и соответственно основное его достоинство сходит на нет.
И после этого что тебя удивляет в том, что адепты БСД не считают, что iptables - рулезом?

>>Разработчики же PF просто не стали изобретать велосипед, и сориентировались на готовый
>>сторонний продукт. И что?
>с одной стороны правильно, с другой какой-то папа карло не изобретает велосипед,
>а покупает венду...   как по мне - так спорное решение...

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

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

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

Но чего ты тогда сюда вообще пишешь? Боишься что все забудут что ты такой удачник и выбрал "правильный" инструмент?

>>Но нет, все равно появится кто-нибудь, кто начнет сравнивать п.пу с п.сей.
>У этих органов разные задачи (пусть даже какую-то часть из них можно
>очертить "опражнением").
>Но сказать, что у фаерволов разные задачи.... то это... ЫЫ а как
>это???

Ну представь, есть такое слово - бронетехника. Есть танки, есть БТР. На одном можно преодолевать водные на другом нет.
Один выдерживает ядерный удар на расстоянии 10 км от эпицентра взрыва, а другой нет. Улавливаешь мысль?


>>Если вам, несчастному, приходится работать со столь устаревшими технологиями как AM FTP,
>>то мы можем вам только посочувствовать.
>Приходиться. И passive и active. Выполненная за глаза задача - чем не
>основание для использования?

Ну, я рад за тебя.

>Но пожалейте лучше себя - продолжать врать себе, что линукс не лучше
>бзд и даже не
>пытаться определить истину...  это жалко (особенно второе, конечно же)

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

Речь шла о том, что iptables в принципе хорош нативной поддержкой active mode FTP, весьма небезопасного варианта ftp протокола. В остальном pf более удобен в использовании для админа.
Это факт. Я использую и тот и другой в своей практике поэтому могу судить об этом. А ты?

Все разумные админы стараются не использовать active mode и это правильно. При этом ничего не теряют, поскольку сейчас трудно найти такой фтп-сервер, который не поддерживает passive mode.

С уважением...

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

74. "Вышел iptables 1.3.8"  +/
Сообщение от _Nick_email (??), 27-Июн-07, 00:39 
>Да причем тут Микрософт? К чему ты его сюда приплел? С чем
>именно ты не согласен в моем утверждении?
С подходом "мне не надо - никому не надо"

>C тем, что FTP  это устаревший протокол?
скажем так, просто старый.

>Если не вдаваться в holy wars, а просто подумать, то согласись, что
>использовать два сокета для банальной передачи файла это напрасная трата ресурсов.
>В свое время это было сделано только в следствии несовершенства АPI стека
>TCP/IP и дифицита оперативной памяти систем.
>На разных машинах могли быть разные кодировки и данные по символьному каналу
>она тупо преобразовывалась в рабочую кодировку локальной машины
>(она могла быть необязательно ASCII), а по бинарному каналу передавались как есть.
>Программы-клиенты получались весьма компактные без лишних заморочек и это было тогда основным
>достоинством протокола.

зато намного лучше библиотеки для конвертирования бинарного/текстового потоков передачи,
логика синхронизации а не дай бог еще и пару потоков для этого придумать...
вот тут да, секономили чем просто
socket(...)
socket(...)
send(n, "GET...")
while () {
   receive()
}


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


>Ха! Не умеет работать через файрволы со стандартным функционалом,
1. не стоить судить по PF о фаерволе
2. читай определение фаервола на Вике - трекинг соединений весьма базовая функциональность, входит в определение.


>например.
>Для этого приходится встраивать специальные структуры в ядро. Городить спецмодули, заботиться о
>их загрузке. Что явно не идет на пользу в плане стабильности
>и надежности.
т.е. если что-то нужно сделать в ядре - то этого делать нельзя потому что
тебе покажеться это "горождением" и "не на пользу стабильности"
Терь понятно почему функционал бздевых ядер столь скромен....
Даже если нужно - то лучше не надо, это будет вредно....
(кстати, вредность еще и от кривизны рук зависит...)


>А не много ли чести для обычного рядового протокола одного из тысяч
>других, почему-то не требующих подобных извратов?
ICMP - обычный? нет?
тоже требует "додобных извратов". ну надо же... странно....


>Угу совместим, но путем неоправданного усложнения других частей системы.
>Он один из многих и далеко не эталон, и только на линуксе...
Оправданного. Смотри об ICMP. (кста, PF ваш так умеет) ?
По исходящему TCP коннекту пропустить назад ICMP port unreach например?
А раз есть одна подсистема - другие протоколы - уже мелочь.


>Одно дело драйвера, а другое дело поддержка рядового, примитивного протокола.
на самом деле речь о подсистеме. В которую, так уж получлось, без проблем вписываеться и FTP протокол. См. про ICMP хотя бы. FTP не одинок, далеко...


>Нет. Это проблема популяризации и широты использования этого продукта.
>На FreeBSD, если я правильно помню, iptables не поддерживает ftр и соответственно
>основное его достоинство сходит на нет.
ты ниче не путаешь? iptables на FreeBSD?? ;)))

>И после этого что тебя удивляет в том, что адепты БСД не
>считают, что iptables - рулезом?
ну, тяжело считать рулезом, что у тебя не работает, как должно %)


>Слушай, _Nick_, ну ты взрослый человек, а? Тебя что, весь мир обидел,
>что тебя тянет всех вокруг оскорблять? Если ты считаешь себя великим
>удачником, то я тебя поздравляю.
Не люблю просто это выражение про отсутсвие универсального инструмента.
И не считаю его правильным.
Ну а про неудачника - извини, реально загнул

>Ну представь, есть такое слово - бронетехника. Есть танки, есть БТР. На
>одном можно преодолевать водные на другом нет.
>Один выдерживает ядерный удар на расстоянии 10 км от эпицентра взрыва, а
>другой нет. Улавливаешь мысль?
улавливаю, но насколько шире понятие бронетехника по сравнению фаервол?
мне кажеться намного шире... отсюда и, очевидно, существование более узких понятий.
Например, тяжелая бронетехника. Или вообще, танк или велосипед %)

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

От количества функционала фаервола его скорость не меняеться.


>В остальном pf более удобен в использовании для админа.
>Это факт. Я использую и тот и другой в своей практике поэтому
>могу судить об этом. А ты?
да, я не могу об этом судить, сравнивая в работе.
Но мне важнее функционал, а удобство - это уже дело скриптов ;)


>Все разумные админы стараются не использовать active mode и это правильно. При
>этом ничего не теряют, поскольку сейчас трудно найти такой фтп-сервер, который
>не поддерживает passive mode.
тут конечно согласен

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

78. "Вышел iptables 1.3.8"  +/
Сообщение от northbear (??), 27-Июн-07, 07:44 
>>Да причем тут Микрософт? К чему ты его сюда приплел? С чем
>>именно ты не согласен в моем утверждении?
>С подходом "мне не надо - никому не надо"

И еще раз... Где я говорил, что мне не надо?

>см. выше. нонче заюзать сокет не столь уж и накладно.

Угу. В ненагруженных системах да хоть десять сокетов.
Но в серьезных системах каждый открытый сокет это время отобранное у контекста приложения. Очевидно, тебе не приходилось сталкиваться с тяжелонагруженными ftp-серверами. На них все еле ворочается.

>>Ха! Не умеет работать через файрволы со стандартным функционалом,
>1. не стоить судить по PF о фаерволе
>2. читай определение фаервола на Вике - трекинг соединений весьма базовая функциональность,
>входит в определение.
>
Ты точно не путаешь tracking со stateful?

>Терь понятно почему функционал бздевых ядер столь скромен....

Дык и стабильность соответственно...

>ICMP - обычный? нет?
>тоже требует "додобных извратов". ну надо же... странно....

...

>Оправданного. Смотри об ICMP. (кста, PF ваш так умеет) ?
>По исходящему TCP коннекту пропустить назад ICMP port unreach например?
>А раз есть одна подсистема - другие протоколы - уже мелочь.

У меня такое очущение, что ты не совсем понимаешь в чем разница между FTP и ICMP в контексте файрвола и что именно делает conntrack_ftp.

Информация на какой хост пропускать обратный icmp-пакет берется из заголовка tcp пакета.

А для FTP, чтобы узнать какой именно порт нужно открыть, откуда, куда и когда закрыть, файрволу приходится отслеживать обмен по 21 порту. А течении сессии может быть открыто и закрыто несколько соединений. Причем они могут быть закрыты не только по команде в символьном канале , но и по таймауту, а может и вообще не быть корректного завершения (например клиентская машина ушла в голубой экран). И т.д. и т.п...

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

>>Нет. Это проблема популяризации и широты использования этого продукта.
>>На FreeBSD, если я правильно помню, iptables не поддерживает ftр и соответственно
>>основное его достоинство сходит на нет.
>ты ниче не путаешь? iptables на FreeBSD?? ;)))

Хм. Да, действительно. Я почему-то думал, что ipfilter во FreeBSD это порт iptables или ipchains'а на худой конец. Извиняюсь за невежество...

>Не люблю просто это выражение про отсутсвие универсального инструмента.

А что разве есть? Тогда расскажи нам про универсальный инструмент, который и летает, и стирает, и удовлетворяет...
Я знаю только один такой. Это моя жена...

>Т.е. функционал скорости и броневой мощи - взаимоисключающие.
>От количества функционала фаервола его скорость не меняеться.

Э-э... Я аж дар речи потерял. А от чего тогда меняется-то? И меняется ли скорость вообще по твоей теории?

С уважением...

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

82. "Вышел iptables 1.3.8"  +/
Сообщение от _Nick_email (??), 27-Июн-07, 11:23 
>Информация на какой хост пропускать обратный icmp-пакет берется из заголовка tcp пакета.
>А для FTP, чтобы узнать какой именно порт нужно открыть, откуда, куда
>и когда закрыть, файрволу приходится отслеживать обмен по 21 порту. А
>течении сессии может быть открыто и закрыто несколько соединений. Причем они
>могут быть закрыты не только по команде в символьном канале ,
>но и по таймауту, а может и вообще не быть корректного
>завершения (например клиентская машина ушла в голубой экран). И т.д. и
>т.п...
>
>И все это файрвол должен отследить и правильно обработать. То есть чтобы
>надежно защитить систему, файрвол вынужден подняться на уровень приложения и знать
>систему команд и логику обмена. Вот это я называю гиморрой...
другие называют функционал.
кто прав?


>А что разве есть? Тогда расскажи нам про универсальный инструмент, который и
>летает, и стирает, и удовлетворяет...
>Я знаю только один такой. Это моя жена...
%)


>Э-э... Я аж дар речи потерял. А от чего тогда меняется-то? И
>меняется ли скорость вообще по твоей теории?
меняеться
но не когда наличиствет N независимых модулей функционала, а эти модули вызывают друг друг
в силу разных причин.
Т.е. если простыми словами:

- вот так вот передавать управление:

switch(n) {
   case 1: go_there1(); break;
   case 2: go_there2(); break;
   case 3: go_there3(); break;
   case 4: go_there4(); break;
....
   case N: go_thereN(); break;
....
}

да, время пердачи управления модулю N растет линейно относительно количества модулей.
Но связка из пары-тройки инструкций сравнения на каждый case это практически несравнимо
мизерные затраты проца относительно роста функционала.
Все равно что бумажку с номером лепить на танк - несравнимо малая нагрузка на мотор, по сравнению с броней.
Посему, я берусь утверждать, что добавить функционал в наше время не есть уменьшить как либо значимо производительность системы. А особо если применяя likely()/unlikely() заоптимизить даже этот поиск более часто используемыми модулями - вообще сказка получиться

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

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

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




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

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