По заявкам трудящихся флейм выделен в отдельную нить.
эх
классный фаерволдо него думал, что ipfw рулит...
Тролль начинающий, наивный - стремительно разпостраняюшийся вид троллей. В Латинской америке известен под именем mudandos, в России имя еще короче, но из уважения к Максиму озвучено не будет :-Р
>Тролль начинающий
пардоньте, вы о сабже?
iptables - это тролль? где вы и что курите? %)
или вы о ТинПу? ;)
Рулит PF как ни крути.
>Рулит PF как ни крути.он уже научилсо видить связь между разными TCP коннектами одной FTP сессии?
он в процессе ;) :-)
вот лет через 5...
>он в процессе ;) :-)
>вот лет через 5...угу
лет через пять они этот процесс наконецто переведут в RUNNING state и начнут девелопить че-то %)
>угу
>лет через пять они этот процесс наконецто переведут в RUNNING state и
>начнут девелопить че-то %)
А типа, пять лет мне ждать без нормально работающего фиреволла?
>>он уже научилсо видить связь между разными TCP коннектами одной FTP сессии?
А какие-нить более значимые аргументы имеются ?:)
>>>он уже научилсо видить связь между разными TCP коннектами одной FTP сессии?
>А какие-нить более значимые аргументы имеются ?:)задача: зарубить ВСЕ входящие коннекты (ну, кроме каких-то стандартных портов, типа ssh и веба), но сделать возможными активные FTP соединения с этого хоста (активные - значит удаленный хост сам коннектиццо насюда чтобы создать поток данных).
слушаю набор правил на PF
>задача: зарубить ВСЕ входящие коннекты (ну, кроме каких-то стандартных портов, типа ssh
>и веба), но сделать возможными активные FTP соединения с этого хоста
>(активные - значит удаленный хост сам коннектиццо насюда чтобы создать поток
>данных).
Вообщето это пассивный режим называется ;-) Но я бы тоже глянул как PF с этим справится :-)
>Вообщето это пассивный режим называется ;-) Но я бы тоже глянул как
>PF с этим справится :-)
нет
может я плохо описал (не было самоцелью)
но активный - это когда ты коннектишься к серверу и даешь ему по этому коннекту команды,
а он к тебе назад коннектиться и отдает по своему коннекту данные.
не веришь - иди читай Вику
Представим (!) что pf это может делать. Как тогда изменится соотношение pf <=> iptables?
>Представим (!) что pf это может делать. Как тогда изменится соотношение pf <=> iptables?
А если б у бабушки был бы ... это был бы дедушка :)
Вот все вам покажи да покажи... Ну читай:
http://openbsd.org/faq/pf/ftp.htmlИ на последок - если iptable не использует проксирование соединения в явном виде то как вы думаете как это делает для iptables соответсвующий хелпер? Сам по себе iptables тоже не умеет работать с данным типо фтп-соединения как и любой другой фаервол.
>Вот все вам покажи да покажи... Ну читай:
>http://openbsd.org/faq/pf/ftp.html
>
>И на последок - если iptable не использует проксирование соединения в явном
>виде то как вы думаете как это делает для iptables соответсвующий
>хелпер? Сам по себе iptables тоже не умеет работать с данным
>типо фтп-соединения как и любой другой фаервол.нашел специалистов по iptables!
ты бы еще цитату с негросайта дал %)))
iptables - модульный (чего, видимо не под силу Pfовцам) и состоит из многих модулей. Один из которых рулит FTP трекингом.
Если это смущает бздунов - это их проблемы.
Но если вы цитируете их логику - то я не побоюсь продолжить эти ваши рассуждения."Само по себе ядро не умеет работать с данными типами сетевух как и любое другое ядро".
В результате вывод: вы жили обмануты бздунами! оказываться даже ядру нужны какие-то модули/драйверы, дабы предоставить пользователю работоспособную систему!
Вот ведь несправедливость, что и iptables работает так же :)
ну модуль-моулем, но вот как он будет "трекать" соединение в данном случае? будет тоже проксирование только под другим соусом...
>ну модуль-моулем, но вот как он будет "трекать" соединение в данном случае?
>будет тоже проксирование только под другим соусом...Ессьно. Да, проксирование.
Но в чем проблема? Ведь это основополагающий принцип.
"Прокси" - примерно значит "ненастощий". Ну так и есть. Под одним ИП живут несколько
клиентов. Конечно этот ИП будет их не настоящий адресс.
И какой фаервол это будет делать - неважно. Но он все равно не виноват в существовании этого принципа :)
Так что непонятен ваш скептицизм по отношению к iptables ;)
да дело не в скептицизме... я лишь пытался сказать что решение применяемое в PF принципиально ничем не хуже того что в IPTables, оно просто другое. А некоторые тут начали заявлять о невозможной/убогой/велосипедной реализации A-FTP через NAT в PF.Нав аш вопрос - "слушаю набор правил на PF" я привел ссылку где этот набор правил имеется. Вот и все:)
>да дело не в скептицизме... я лишь пытался сказать что решение применяемое
>в PF принципиально ничем не хуже того что в IPTables, оно
>просто другое. А некоторые тут начали заявлять о невозможной/убогой/велосипедной реализации A-FTP
>через NAT в PF.
да, согласен. Естественно, PF (ровно как и IPFW) хватает за глаза на большинстве
систем.
Просто iptables предоставляет больше возможностей, да и вкупе с остальными плюсами
самого Линукса - более интересное решение :)
>Нав аш вопрос - "слушаю набор правил на PF" я привел ссылку
>где этот набор правил имеется. Вот и все:)
А :) Ну вот оттуда и решил.
Просто человек специально не нуждавшийся в подобном решении под BSD (и не пользующийся гуглем ;)
не будет знать о том, что оно есть %)
ня. а давайте для каждого протокола использовать юзерспейсовый костыль. А ещё лучше запускать его из inetd. Процессоры то нынче быыыыстрые.У меня вопрос поинтереснее: а как вы десяток pptp/sip/h.323 сессий из серой сети выпустите?
http://www.openbsd.org/faq/pf/ftp.html
>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 протокол %))..сурова жизть бздшников...
Ваш сарказм явно не в тему. :))FTP - откровенно устаревший протокол, созданный во времена, когда про безопасность никто даже не помышлял. И файрволы - это были диковинные программули, создающие проблемы для других.
Совершенно очевидно, что Active Mode FTP мало совместимо с ЛЮБЫМИ файрволами.И в iptables тоже, чтобы работать с AM FTP необходимо грузить дополнительный модуль (тот же самый по сути ftp-proxy), который жестко завязывается на функционал ядра. Из-за этого портирование iptables с полным Linux'овым функционалом на другие ОС практически не возможно. И говорить, что iptables без проблем работает c такими FTP-соединениями вряд ли можно. Проблемы там есть.
Разработчики же PF просто не стали изобретать велосипед, и сориентировались на готовый сторонний продукт. И что?
Сколько уже говорилось, что универсальных инструментов нет! Каждый инструмент хорош для своей задачи. Но нет, все равно появится кто-нибудь, кто начнет сравнивать п.пу с п.сей.
Если вам, несчастному, приходится работать со столь устаревшими технологиями как AM FTP, то мы можем вам только посочувствовать.Единственной причиной, по которой нельзя воспользоваться passive mode, может быть лишь неспособность софта на удаленной стороне работать в этом режиме. А это, как говорится, клинический случай. Тут нужен врач...
С уважением...
>Ваш сарказм явно не в тему. :))
возможно
Люблю обсуждать проблемы неЛинукса ;)
Эдакая война не на своей территории :)
>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. Выполненная за глаза задача - чем не основание для использования?
Но пожалейте лучше себя - продолжать врать себе, что линукс не лучше бзд и даже не
пытаться определить истину... это жалко (особенно второе, конечно же)
>ГЫЫЫЫ
>первая мысль по поводу: "у меня не работает (плохо работает) - значит
>никому не надо (устарело)"
>вторая мысль: "маркетолог негросовта: М%я! Вы все еще используете протокол, созданный больше
>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 тем, что 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.
тут конечно согласен
>>Да причем тут Микрософт? К чему ты его сюда приплел? С чем
>>именно ты не согласен в моем утверждении?
>С подходом "мне не надо - никому не надо"И еще раз... Где я говорил, что мне не надо?
>см. выше. нонче заюзать сокет не столь уж и накладно.
Угу. В ненагруженных системах да хоть десять сокетов.
Но в серьезных системах каждый открытый сокет это время отобранное у контекста приложения. Очевидно, тебе не приходилось сталкиваться с тяжелонагруженными 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'а на худой конец. Извиняюсь за невежество...
>Не люблю просто это выражение про отсутсвие универсального инструмента.
А что разве есть? Тогда расскажи нам про универсальный инструмент, который и летает, и стирает, и удовлетворяет...
Я знаю только один такой. Это моя жена...>Т.е. функционал скорости и броневой мощи - взаимоисключающие.
>От количества функционала фаервола его скорость не меняеться.Э-э... Я аж дар речи потерял. А от чего тогда меняется-то? И меняется ли скорость вообще по твоей теории?
С уважением...
>Информация на какой хост пропускать обратный 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() заоптимизить даже этот поиск более часто используемыми модулями - вообще сказка получиться
а iptables уже научилсо работать с таблицами?
>а iptables уже научилсо работать с таблицами?
http://www.snowman.net/projects/ipt_recent/
А как pf спарвляется с vpn сессиями, насколько мне помнится, он только одну через nat пускал, это единственная причина почему я его сменил, так он очень даже хорош.
А что, простите, такое VPN? PPTP, IPSEC, L2TP/IPSEC, OpenVPN? Или что другое?
pptp из локалки
дык он если не ошибаюсь по GRE бегает, а уж его от-conntrack'ать раньше и iptables не сильно умели... незнаю, правда, как сейчас...
>дык он если не ошибаюсь по GRE бегает, а уж его от-conntrack'ать раньше и iptables не сильно умели... незнаю, правда, как сейчас...#lsmod
ip_nat_proto_gre
ip_nat_pptp
ip_conntrack_pptp
ip_conntrack_proto_greЕще вопросы есть?
Вообще-то, да:
работает ли при этом одновременно несколько pptp клиентов, цепляющихся из-за одного маскарада на один pptp сервер снаружи?
пару лет назад вроде не работало...
>работает ли при этом одновременно несколько pptp клиентов, цепляющихся из-за одного маскарада
>на один pptp сервер снаружи?
>пару лет назад вроде не работало...Сдается мне, что ни когда так работать не будет. Врожденное ограничение РРТР: GRE имеет только один механизм адресации - IP адрес. Портов, как у TCP и UDP нету. Соответственно, из под НАТа с одним внешним адресом возможна только одна сессия РРТР. Возможный выход: алиасы на внешнем интерфейсе с реальными адресами и для каждого внутреннего клиента РРТР делать НАТ через уникальный внешний адрес.
на самом деле заголовок GRE пакета имеет "Key (LW) Call ID":
Contains the Peer's Call ID for the session to which this packet belongs.
Также имеются "Sequence Number" и "Acknowledgment Number"...
Так что теоретически соответствующий conntrack модуль может разрулить к какому соединению относится пакет... другой вопрос, что в Debian 3.1 (Sarge) с 2.6.8 и модулей таких, если не ошибаюсь, небыло...
>на самом деле заголовок GRE пакета имеет "Key (LW) Call ID":
>Contains the Peer's Call ID for the session to which this packet belongs.
Используется ли он на самом деле? В заголовках IP пакетов есть много полей, которые реально не используются.>Также имеются "Sequence Number" и "Acknowledgment Number"...
Эти, похоже, нужны только для сборки правильной последовательности. Вряд-ли по ним получится идентифицировать сессию
>Используется ли он на самом деле? В заголовках IP пакетов есть много
>полей, которые реально не используются.
Очень может быть... Но если оно действително не используется - может возможно как раз использовать это поле при nat'е по назначению :-)А вообще, ISA то эту ситуацию как-то разруливать умеет...
>дык он если не ошибаюсь по GRE бегает, а уж его от-conntrack'ать
>раньше и iptables не сильно умели... незнаю, правда, как сейчас...
Не сей час и некогда он не бегал по GRE..:)
> Не сей час и некогда он не бегал по GRE..:)RTFM! PPTP всегда ездил по TCP(управление)+GRE(данные).
В продолжение темы iptables vs ipfwКогда ipfw научится делать так?
iptables -A INPUT -p tcp --dport 25 -m geoip ! --src-cc RU,UA -j DROP
(это означает дропать попытки любых соединений на 25-й порт, если IP адрес удаленного хоста не в России, или Украине)
Производительность данного правила сомнительна, если оно берет всегда свежие данные о распределении адресов по Украине и России.Если же оно берет данные на момент загрузки правила в ядро, то такое реализуется таблицами в любом файрволле: скриптом продергивается пул адресов и засовывается в таблицу перед загрузкой правила на запрет соединений из этой таблицы. Более того, можно эту таблицу непрерывно мониторить и добавлять/удалять туда только необходимые адреса, а не перегружать её целиком.
Я так понимаю этот вопрос.
>Производительность данного правила сомнительна, если оно берет всегда свежие данные о распределении адресов по Украине и России.Не только по Украине и России, а по всем распределенным адресам мира.
ls -l /var/geoip
-rw-rw-r-- 1 root root 727284 2007-06-24 01:10 geoipdb.bin
-rw-rw-r-- 1 root root 1398 2007-06-24 01:10 geoipdb.idxЛокальная база распределения адресов по странам. Обновляется раз в месяц.
Производительность замечательная, т.к. эта база - хэш с индексами.
Облизывайтесь...
>Облизывайтесь...
ipset - намного правильнее.Это данные надо в памяти держить.
>Это данные надо в памяти держитьДисковый кэш нас уже не устраивает?
CISCO придумала засунуть в IP-фильтр инспекцию протоколов и с тех пор началась гонка между реализациями МСЭ.Никто бы не умер без возможности active mode FTP так как уже всё перевели на Passive. PPTP через NAT не ходит ? Много всяких комбинаций не может работать так как не предусмотренно изначально. Давайте теперь придумаем как IPSec AH через NAT пропихнуть ?
Я думаю, что следует отказываться от решения проблем такими вот "прибамбасиками". Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работы. Следует стремится сохранять понятийную простоту и логичность экплуатируемой системы а не увеличивать комбинаторную нагрузку на мозг.
> CISCO придумала засунуть в IP-фильтр инспекцию протоколов и с тех пор началась гонка между реализациями МСЭ.не совсем по тебе, но это придумала фирма Check Point...
>> CISCO придумала засунуть в IP-фильтр инспекцию протоколов и с тех пор началась гонка между реализациями МСЭ.
>
>не совсем по тебе, но это придумала фирма Check Point...
если не ошибаюсь, зовётся всё это nat traversal и состоит в инкапсуляции в udp-пакет.
Поддерживаю на все 100000%
золотые слова
>Никто бы не умер без возможности active mode FTP так как уже
>всё перевели на Passive.Вообще режимы ftp позволяют перемещать данные с сервера на сервер.
>Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работыА вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы Московского представительства. А доступ в коропративную сеть организован только по РРТР. И вот приезжают пяток менеджеров оттуда со своими ноутами и все хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что из под НАТа возможна только одна сессия РРТР?
>>Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работы
>
>А вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы
>Московского представительства. А доступ в коропративную сеть организован только по РРТР.
>И вот приезжают пяток менеджеров оттуда со своими ноутами и все
>хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что
>из под НАТа возможна только одна сессия РРТР?
хороший повод проэскалировать, не правда ли? :)
>>Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работы
>
>А вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы
>Московского представительства. А доступ в коропративную сеть организован только по РРТР.
>И вот приезжают пяток менеджеров оттуда со своими ноутами и все
>хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что
>из под НАТа возможна только одна сессия РРТР?
В данном случае проблема организационная: московского инженера не предупредили чтобы он мог подготовится. Взять у провайдера пяток IP-адресов не трудно. Где тут техническая проблема ?NAT зря придумали так как он сколько проблем решает столько и создаёт.
>NAT зря придумали так как он сколько проблем решает столько и создаёт.Белко, где ты такие пастбища берешь?
подумай столько бы народу было без инета отмени сейчас NAT.
Да, может IPv6 быстрее бы ввели. Но NAT [почти] решает не только проблему нехватки ИПшников.
Может я не до конца понял, но у меня успешно бегают несколько пптп сессий через нат и мало того эти сессии ходят через такой же пптп тунель.
----pptp1Client------\
\
---NAT---pptpISP---ISP--INTORNET-----PPTPSERVER
/
----pptp2Client------/FreeBSD + mpd + natd
>FreeBSD + mpd + natd
ключ ко всему - natd. Он на libalias и нормально умеет работать с pptp.
>>Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работы
>
>А вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы
>Московского представительства. А доступ в коропративную сеть организован только по РРТР.
>И вот приезжают пяток менеджеров оттуда со своими ноутами и все
>хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что
>из под НАТа возможна только одна сессия РРТР?гы...
не повеЗЛО...
ну а вообще ж виновник то кто распространения это недопротокола... негросовт...
свое писать не умеют и нихрена не соображают - лицензировали первое попавшееся...
А ведь уже тогда проблема айпишников была не за горами...
Но великая контора то дальше своего носа не видит...еще один повод ее ненавидеть? (но куда ж больше??)
>>хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что
>>из под НАТа возможна только одна сессия РРТР?
>
>гы...
>не повеЗЛО...
>ну а вообще ж виновник то кто распространения это недопротокола... негросовт...
>свое писать не умеют и нихрена не соображают - лицензировали первое попавшееся...А по-моему виновник в этом NAT ибо он является самым настоящим сетевым хаком, принцип работы которого нарушает основы (независимость уровней, глобальная схема адресации, уникальность адресов). Всё шло от невинного к более противному. Сначала был Static NAT, затем придумали динамическое распределение. Но когда добавили PAT и соотношение 1:1 нарушили (одномоментно один внешний адрес обслуживает несколько внутренних) вот тогда-то и начались настоящие проблемы. Хак усилился - усилились проблемы. Прямая связь.
тебе вредно раниматься IT :)
причем вредно именно для нее ;)любой хак, делающий счастливыми население Земли - есть благо.
Остальное - проблемы ИТшников :) (причем не очень то и большие ;)
>еще один повод ее ненавидеть? (но куда ж больше??)Куда больше в данном случае всегда найдется. Случай такой.
Пока работал над PPTP и L2TP столько слов ярких по поводу вырвалось. L2TP - красиво реализованный, расширяемый протокол работающий по UDP. PPTP же, напротив, жестко фиксированное уродство с кучей странных заточек работающее по TCP+GRE. Не знаю в каком году PPTP разработали, но RFC на них опубликованы с интервалом в месяц в 1999 году.
В общем, да здравструет L2TP без IPSec - идеальный вариант! :)
>А вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы Московского представительства. А доступ в коропративную сеть организован только по РРТР. И вот приезжают пяток менеджеров оттуда со своими ноутами и все хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что из под НАТа возможна только одна сессия РРТР?Поставьте им di-804hv или любой другой длинковский роутер 800-й серии. Он умеет пускать несколько pptp сессий через свой нат. Да и коннектится ко всем pptp серверам.
>Поставьте им di-804hv или любой другой длинковский роутер 800-й серииЗа совет про D-Link спасибо, конечно. Только проблема решилась проще. На линуксе поставил pptp-client, организовал маршрутизацию между сетями по этому туннелю. Всем стало хорошо.
> Поставьте им di-804hv или любой другой длинковский роутер 800-й серии.
>Он умеет пускать несколько pptp сессий через свой нат. Да и
>коннектится ко всем pptp серверам.
внутри таких вот длинков, как правило, linux.
Как и внутри всяких ZyWall.
>>Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работы
>
>А вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы
>Московского представительства. А доступ в коропративную сеть организован только по РРТР.
>И вот приезжают пяток менеджеров оттуда со своими ноутами и все
>хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что
>из под НАТа возможна только одна сессия РРТР?
И нет не какого объединения локалок? Такого не быват...(ну разве что в прошлом веке, так что проблема не ваша а головной конторы)
>>Всегда есть альтернатива в виде изменения сетевой структуры под задачи вместо усложнения и запутывания работы
>
>А вот не всегда! Головному офису крупной Бельгийской конторы начхать на проблемы
>Московского представительства. А доступ в коропративную сеть организован только по РРТР.
>И вот приезжают пяток менеджеров оттуда со своими ноутами и все
>хотят (вот сволочи!) читать почту из Брюсселя. Как им объяснить, что
>из под НАТа возможна только одна сессия РРТР?Обалдеть! И одновременно тут же крансоглазики пытаются унизить FreeBSD. У меня стоит штатный natd и весь офис когда ему заблагорассудится по PPtP ходит в другой со своего компа.
>Обалдеть! И одновременно тут же крансоглазики пытаются унизить FreeBSD.Да чего там унижать. sip/h.323/irc(dcc)/tftp и приплыли.
>У меня стоит штатный natd
вот и сидите на жалких 2Мбит. А сколько ваш natd будет жрать cpu при 100мбит?
>вот и сидите на жалких 2Мбит. А сколько ваш natd будет жрать
>cpu при 100мбит?Для желающих 100мбит есть его netgraph версия по имени ng_nat.
>>вот и сидите на жалких 2Мбит. А сколько ваш natd будет жрать
>>cpu при 100мбит?
>
>Для желающих 100мбит есть его netgraph версия по имени ng_nat.угу. + ещё в 7ке nat в ipfw.
Только у ng_nat есть минус - несколько нетривиальный интерфейс.
Уж как-то проще nat on em0 from $local_nat to !$local_net -> em0 чем все эти интуитивно-понятные ngctl ...
>>>вот и сидите на жалких 2Мбит. А сколько ваш natd будет жрать
>>>cpu при 100мбит?
>>
>>Для желающих 100мбит есть его netgraph версия по имени ng_nat.
>
>угу. + ещё в 7ке nat в ipfw.Ну это по вкусу. Это все тот-же libalias в ядре, что и в случае ng_nat.
>Только у ng_nat есть минус - несколько нетривиальный интерфейс.
>Уж как-то проще nat on em0 from $local_nat to !$local_net -> em0 чем все эти интуитивно-понятные ngctl ...В связке с фаерволом ng_nat конечно описывается через одно место. Но это действительно изврат, а вот в связке с ng интерфейсом, например при использовании mpd, он самое то, что надо.
>Обалдеть! И одновременно тут же крансоглазики пытаются унизить FreeBSD. У меня стоит
>штатный natd и весь офис когда ему заблагорассудится по PPtP ходит
>в другой со своего компа.Ворвался. Увидел знакомые слова. Читать тред некогда - надо срочно свое слово вставить.
Расскажи-ка, милый, как же это у тебя весь офис "когда ему заблагорассудится по PPtP ходит"? Обсуждается ситуация, когда несколько клиентов из-под НАТа ОДНОВРЕМЕННО соединяются по РРТР с ОДНИМ сервером. Попробуй для начала, а потом про FreeBSD и "красноглазиков" трындеть будешь.
А что мешает повесить отвести под пассивный фтп диапазон портов где то за 64000 и открыть их ;)
>А что мешает повесить отвести под пассивный фтп диапазон портов где то
>за 64000 и открыть их ;)- безопасность
- спорт
- изначальное условие (ну это так, для сугреву) ;)
>- безопасность
>- спорт
>- изначальное условие (ну это так, для сугреву) ;)А можно real-life проблему?
И где тут реально проблемы с безопасностью?
>А можно real-life проблему?
"спорт" видел?
это не жизненноважный пример, конечно.
так что не баись>И где тут реально проблемы с безопасностью?
больше доступа к твоему хосту от FTP сервака чем нужно.
Теоретически, это меньший уровень безопасности, чем пропускать лишь пакеты от нужного порта на нужный.
Да, кстати, на фтп сайт который не работает в пассиве я просто не пойду. Это его проблема а не моя.
>Да, кстати, на фтп сайт который не работает в пассиве я просто
>не пойду. Это его проблема а не моя.конечно ж не пойдешь %))
ибо некак :D
либо придеццо ж*опу выставлять в сетку на время посещения ;)))
>>Да, кстати, на фтп сайт который не работает в пассиве я просто
>>не пойду. Это его проблема а не моя.
>
>конечно ж не пойдешь %))
>ибо некак :D
>либо придеццо ж*опу выставлять в сетку на время посещения ;)))Зачем ? Stateful фильтрацию для кого придумали ? Если на данный хост установлена ftp-command сессия, то принимать с него-же на определенный диапазон портов ftp-data.
>Зачем ? Stateful фильтрацию для кого придумали ? Если на данный хост
>установлена ftp-command сессия, то принимать с него-же на определенный диапазон портов
>ftp-data.это все равно открывает больше доступа к твоему хосту, чем нужно.
С этого хоста на эти высокие порты в это время сможет законнектиться не только
FTP сервер...Паранойа это или же просто спорт... но, надеюсь, вы согласны с мои утверждением
>конечно ж не пойдешь %))
>ибо некак :D
>либо придеццо ж*опу выставлять в сетку на время посещения ;)))Я уже давно по фтп никуда не хожу. Меня вообще удивляет что до сих пор есть такой "сервис". А если админы удалённого сайта не знают как настроить пассив - я глубоко сомневаюсь что там есть чтото полезное.
Так что iptables решает проблемы которые не возникают ;)