Вышел стабильный релиз flex-fw (http://code.google.com/p/flex-fw/), небольшой и быстрой надстройки (front-end) для Linux утилиты iptables с простым синтаксисом команд, напоминающем ipfw из FreeBSD или pf из OpenBSD.
Возможности:
- Сервис-ориентированная конфигурация, позволяет стартовать или останавливать доступ к каждому сервису раздельно и независимо, без остановки всей системы flex-fw целиком;
- Поддержка сетевых профилей /etc/net (http://etcnet.org/). Можно работать с различным сетевым окружением без какой либо перенастройки flex-fw;
- Поддержка макросов. Макрос - это переменная, определяемая пользователем, которая может хранить IP-адрес, номер порта, имя интерфейса и т.п.
- Простая миграция - достаточно переопределить макросы для переноса на другой хост, в другое сетевое окружение;
- Тиражирование. Описывая сервисы с использованием макросов можно легко перенести сервисы на все обслуживаемые хосты без каких либо изменений;
- Простая отладка. Поддержка вывода чере...URL: http://code.google.com/p/flex-fw/wiki/RussianHomePage
Новость: http://www.opennet.me/opennews/art.shtml?num=22605
гибче iptables чтоли? Не верю! (с) Станиславский
не припоминаю что бы Станиславский что-то говорил про iptables...
что-то маловато дистрибов поддерживается
>что-то маловато дистрибов поддерживаетсяПока поддерживаю то, с чем работаю сам. Если есть желание помочь - буду крайне признателен за любое содействие.
Сделайте пожалуйста ebuild для gentoo, думаю, многим будет полезно.
iptables не дистрибутив :)
да iptables - это хорошо, но в совем изначальном виде, т.е. его обычные правила - это жесть.недавно старый сервер надо было немного поменять (fw скрипт) да полчаса вспоминал что да как. вспомнил!
>да iptables - это хорошо, но в совем изначальном виде, т.е. его обычные правила - это жесть.Именно. iptables в тепершнем виде - ассемблер фактически. Чтобы выполнить _обычное_ действие (открыть порт, например), нужно написать несколько правил (+отдельно для NAT-ов), не забыть про ip_forward и, бывает, загрузить модули ядра, очень желательно учесть взаимозависимости, не наступить на "особенности" с порядком правил и не очепятаться в множестве длиннющих строк. И неплохо бы, чтоб stateful. И чтоб безопасно -- обязательно. ... %-l
>недавно старый сервер надо было немного поменять (fw скрипт) да полчаса вспоминал что да как. вспомнил!
А выбрал бы и использовал генератор правил -- глядишь, список вспоминаемых правил был бы раз в *цать http:/openforum/vsluhforumID1/81413.html#7 (*) короче. Вспоминалку не так напрягать пришлось бы. Хотя на вкус, на цвет... Многие продолжают пилить iptables/#EXAMPLESCRIPTS, кому-то и "чистый" iptables |) _нравится_.
Поэтому обёрток и генераторов правил -- вагон с тележкой. И у каждого - свои ограничения...
Например, на что уж мне нравится firehol, но в его входном языке не учтена связь между nat-ами и соответствующими фильтрами -- приходится (~всё равно) два набора правил писать... И да, сам мучительно вспоминаю, чего нагородил http:/openforum/vsluhforumID1/82424.html#3 на firehol с кучей разных групп ip с разными nat-ами с фильтрами...Совершенства нет. Поэтому и появляются новые обёртки-генераторы.
Вот, глядишь, выйдет nftables http:/openforum/vsluhforumID3/50862.html -- будет одна обёртка для всех. Пока и её :) не начнут обёртывать.
(*) При этом _читать_ iptables-save и понимать, как оно там устроено внутри -- тоже неплохо, если не обязательно, - для полной уверненности.
>Например, на что уж мне нравится firehol, но в его входном языке
>не учтена связь между nat-ами и соответствующими фильтрами -- приходится (~всё
>равно) два набора правил писать...Спасибо за идею, возможно возьму на вооружение.
>(*) При этом _читать_ iptables-save и понимать, как оно там устроено внутри
>-- тоже неплохо, если не обязательно, - для полной уверненности.Абсолютно с вами согласен. Никакая обертка не должна исключать знание мат-части. Задача обертки не в замене инструмента, а в упрощении автоматизации повседневной работы.
Ага, это вы бландинкам за рулём лексуса расскажите.
>>недавно старый сервер надо было немного поменять (fw скрипт) да полчаса вспоминал что да как. вспомнил!
>
>А выбрал бы и использовал генератор правил -- глядишь, список вспоминаемых правил
>был бы раз в *цать http:/openforum/vsluhforumID1/81413.html#7 (*) короче. Вспоминалку не так
>напрягать пришлось бы. Хотя на вкус, на цвет... Многие продолжают пилить
>iptables/#EXAMPLESCRIPTS, кому-то и "чистый" iptables |) _нравится_.не знаю, но почему то после ваших слов всякая обвертка для fw стала оссоциироваться с графическим интерфейсом на сервере ;)
хотя на счет вкуса я согласен
но почему то как то вот сложилось, если уж браться за что то до пилить до конца, во всяком случае если это интересно или других вариантов нет ;
Новый велосипед? Чем лучше Shorewall или хотя бы ferm?
Увы, новый. Насчёт лучше - не уверен, но есть возможность управлять доступом к конкретным сетевым сервисам, при этом никак не затрагивая доступ к остальным, и уж тем более не перезапуская систему фильтрации целиком (что зачастую чревато обрывом уже установленных соединений).
>возможность управлять доступом
>к конкретным сетевым сервисам, при этом никак не затрагивая доступ к
>остальным, и уж тем более не перезапуская систему фильтрации целиком (что
>зачастую чревато обрывом уже установленных соединений).Системный подход к решению практических задач.
опять эти велосипеды. есть уже ufw, shorewall и еще вагон с маленькой тележкой этих надстроек. и все из-за убогого синтаксиса и логики построения правил в iptables.
почему то для ipfw и pf таких надстроек не используют - вменяемый синтаксис (особенно у pf) изначально был заложен разработчиками.
>опять эти велосипеды. есть уже ufw, shorewall и еще вагон с маленькой
>тележкой этих надстроек. и все из-за убогого синтаксиса и логики построения
>правил в iptables.
>почему то для ipfw и pf таких надстроек не используют - вменяемый
>синтаксис (особенно у pf) изначально был заложен разработчиками.АБСОЛЮТНО ТРЕМЯ РУКАМИ ЗА!
Очень правильная мысль у Вас - на счет велосипедов, окружающих настройку iptables.
Почему интересно разработчики об этом не задумываються.
>опять эти велосипеды.
>почему то для ipfw и pfЫ? :)) Что-то мне подсказывает, что это не все _ваши_ велосипеды?
>опять эти велосипеды. есть уже ufw, shorewall и еще вагон с маленькой
>тележкой этих надстроек. и все из-за убогого синтаксиса и логики построения
>правил в iptables.Никто не ругает ассемблер за убогость синтаксиса и логики работы через регистры процессора. Его просто используют те, кому это действительно нужно. Остальные применяют обертки в виде компиляторов и интерпретаторов. Правда среди них тоже мало счастливых и всем довольных... :)
>почему то для ipfw и pf таких надстроек не используют - вменяемый
>синтаксис (особенно у pf) изначально был заложен разработчиками.Возможно разработчики pf просто имели больший опыт в разработке дружественных интерфейсов. Пускай даже и интерфейсов командной строки... :)
А чем он от убунтовского ufw отличается, который тоже с похожим на pf синтаксисом? Например:ufw allow proto tcp from any to any port 22
ufw allow from 192.168.0.0/16
ufw insert 3 deny to any port 22 from 10.0.0.135 proto tcp
>А чем он от убунтовского ufw отличается, который тоже с похожим на
>pf синтаксисом?Хотя бы тем, что ufw никто не переносил на Slackware и не планирует делать это для RedHat. Да и не былы ничего слышно про ufw в августе 2003 года. Как, впрочем, и об Ubuntu...
А вообще, я бы на синтаксисе вообще не концентрировал внимание. Упрощённый синтаксис - это скорее побочный продукт, в начале разработки о нем как-то и не задумывались, хватало нескольких функций-макросов. Основными плюсами я считаю сервис-ориентированность, возможность манипуляции доступом к конкретным сервисам независимо от других, без внесения в их работу каких-либо помех, и легкость миграции в другое сетевое окружение. При введении простых стандартов на макросы получаем возможность прозрачного переноса описаний сервисов между хостами в обслуживаемом парке маршрутизаторов.
>в их работу каких-либо помех, и легкость миграции в другое сетевое
>окружение. При введении простых стандартов на макросы получаем возможность прозрачного переноса
>описаний сервисов между хостами в обслуживаемом парке маршрутизаторов.Кстати раз уж зашла об этом речь! Осмелюсь у Вас, да в прочем и у всех!
У меня три маршрутизатора на pf и честно сказать я в ужасе. У кого какие методики есть.
Может примеры конфигов, сценариев (iptables)
Интересует как pf так и iptables.
Можете поделиться ? можно на мыло, если ну сами понимаете
спасибо
Не совсем понятно что вызывает у вас ужас. В чем суть проблемы?
Может обсуждение проблемы переведем на форум - к этой новости это наверняка отношения не имеет?
А как в ufw по простому привязывать правила не к порту, а к интерфейсу хотя бы?
А мне нравится синтаксис iptables и не нуждаюсь во всяких приблудах
что-то мне казалось, что синтаксис у pf и ipfw ну сильно различается
по крайней мере идеи заложенные в их ситаксис очень разнятся
>что-то мне казалось, что синтаксис у pf и ipfw ну сильно различается
>
>по крайней мере идеи заложенные в их ситаксис очень разнятсяне знаю как у ipfw и pf
а вот pf и iptables - точно, идея и реализация FW разные, точнее есть нюансы, которые если их не знать то сделать хороший FW не представляеться возможным.
А вообще я заметил, лично по себе, забываеться что то, что это. Каждый раз приходиться вспоминать а это же pf у него так; а это же iptables здесь нужно так
Это личное впечатление от настройки FW-ов
Пользую iptables в оригинале уже, дай бог памяти, лет пять. О всякого рода надстройках даже не задумывался. Синтаксис команд вполне понятный и легко осваиваемый нужно просто включить мозги.
>Пользую iptables в оригинале уже, дай бог памяти, лет пять. О всякого
>рода надстройках даже не задумывался. Синтаксис команд вполне понятный и легко
>осваиваемый нужно просто включить мозги.лично я не спорю
все понятно, понятный синтаксис, главное гибкийно у pf это более абстрагировано от реальной организации стека и все что с нм связано
как то более на человека подобном языке а не на машинно
если можно так сказатьсогласны?
Если кратко, синтаксис pf можно описать одним словом - негибкий.Для интерфейса к любой сложной системе простота и удобство противопоставляются.
Чем проще интерфейс - тем он менее удобен.
Чем удобнее - тем больше нужно шевелить мозгами, чтобы понять его. Примеры: vim, emacs, awesome, xmonad. Но зато после определенного движения мысли, эффективность работы значительно возрастает по сравнению с простым интерфейсом.
>Если кратко, синтаксис pf можно описать одним словом - негибкий.Это у PF-а то синтаксис не гибкий? Вы когда нибудь на OpenBSD маршрутизатор с FW делали? Много-портовый?
>Для интерфейса к любой сложной системе простота и удобство противопоставляются.
>Чем проще интерфейс - тем он менее удобен.Ваши слова истинная правда, если учесть что синтаксис iptables в N раз проще чем синтаксисPF. :) Ассемблер имеет много достоинств. Но на С писать проще, быстрее и, если программа большая, то и надёжнее. Т.к. синтаксис читабельней чем у ассемблера на несколько порядков.
>Если кратко, синтаксис pf можно описать одним словом - негибкий.
>
>Для интерфейса к любой сложной системе простота и удобство противопоставляются.
>Чем проще интерфейс - тем он менее удобен.
>Чем удобнее - тем больше нужно шевелить мозгами, чтобы понять его. Примеры:
>vim, emacs, awesome, xmonad. Но зато после определенного движения мысли, эффективность
>работы значительно возрастает по сравнению с простым интерфейсом.много чего в мире не гибкого, при том, что это совсем не характеризует не гибкий "предмет" как не соответствующий требованиям и функциям ему предъявляемым или в него залеженным.
да pf за счет синтаксиса скрывает тонкости реализации, и поэтому может не всегда понятно как он работает, пока не поймешь как же это будет на его языке.
iptables напротив нужно один раз понять, но понять так широко и с такими вытекающими, что написать правило будет гораздо сложнее нежели для pf и будет это гораздо трудоемней.
Вообще у этих двух fw много отличий. Ну вот например tcnm еще одно отличие iptables от pf это порядок правил или цепочек. в pf он строго задан разработчиком, в iptables наоборот ты сам себе хозяин.
с iptables - пока не проколешься не поймещь. с pf - это гораздо менее вероятнее ИМХО.
Разве машинный код придумали не люди? Или скайнет захватил мир? :D
Так или иначе каждый выбирает для себя свой, на его взгляд, удобный инструмент.
>Пользую iptables в оригинале уже, дай бог памяти, лет пять. О всякого
>рода надстройках даже не задумывался. Синтаксис команд вполне понятный и легко
>осваиваемый нужно просто включить мозги.Использую iptables в оригинале с момента его появления. О надстройках задумался когда в количество сопровождаемых маршрутизаторов со схожими задачами, а следовательно и настройками фаервола, перевалило за второй десяток. И практически каждый день приходилось вносить в эти настройки изменения, практически одинаковые для нескольких хостов. И мозгами тут уже не пахло - тупая рутина...
>>Пользую iptables в оригинале уже, дай бог памяти, лет пять. О всякого
>>рода надстройках даже не задумывался. Синтаксис команд вполне понятный и легко
>>осваиваемый нужно просто включить мозги.
>
>Использую iptables в оригинале с момента его появления. О надстройках задумался когда
>в количество сопровождаемых маршрутизаторов со схожими задачами, а следовательно и настройками
>фаервола, перевалило за второй десяток. И практически каждый день приходилось вносить
>в эти настройки изменения, практически одинаковые для нескольких хостов. И мозгами
>тут уже не пахло - тупая рутина...Для тупой рутины есть bash, perl, etc....
>>И мозгами тут уже не пахло - тупая рутина...
>
>Для тупой рутины есть bash, perl, etc....Собственно, с простенького башевского скрипта за несколько лет все это плавно переросло в flex-fw :)
зачем обертки? используйте оригинал! луиджи же недавно портировал ipfw на Linux =)
iptables, (точнее, Netfilter) пожалуй, самое мощное бесплатное средство работы с сетевым стеком. Все эти "упрощалки" на самом деле усложняют(!) работу системы. Достаточно один раз понять, как проходят пакеты через netfilter, освоить правило создания команд, и вуаля! - можно делать все что угодно с пакетами - маркировать для других нужд, журналировать попытки доступа, блокировать злоумышленников с частыми запросами к определенным сервисам и автоматически снимать блокировки через установленные промежутки времени. И всего-то что нужно прочитать - man iptables.
>iptables, (точнее, Netfilter) пожалуй, самое мощное бесплатное средство работы с сетевым стеком.Абсолютно уверен в том-же!
>Все эти "упрощалки" на самом деле усложняют(!) работу системы.Как это не парадоксально - но это факт! Внесение дополнительной логики в любую систему может ее только усложнить. Я думаю что любыми обертками следует пользоваться только досконально изучив работу самого iptables. И рассматривать их не как средство упрощения синтаксиса, а как средство минимизации затрат времени при решении ряда весьма специфичных задач.
> И всего-то что нужно прочитать - man iptables.
А вот здесь категорически не согласен. Одного мана для понимания работы пакетного фильтра в Linux будет явно не достаточно. Придётся еще почитать документацию и статьи с netfilter.org...
Упрощалки упрощалкам рознь.
При большом количестве правил все равно приходится писать свой скрипт, то есть собственную упрощалку, так почему бы не использовать уже написанную, поддерживаемую и с понятным синтаксисом.Использовал firehol http://firehol.sourceforge.net/, действительно удобно писать простые правила и не менее удобно сложные, использовать свои скрипты и т.д.
>А вот здесь категорически не согласен. Одного мана для понимания работы пакетного
>фильтра в Linux будет явно не достаточно. Придётся еще почитать документацию
>и статьи с netfilter.org...Зачем? Ведь уже есть для ленивых и на русском http://www.opennet.me/docs/RUS/iptables/
А etcnet тоже, кстати, имеет встроенную поддержку iptables, ipv6tables и ebtables.
http://www.altlinux.org/Etcnet/firewall
Это если вдруг кто не знал, т.к. штатно он выключен.
> allow forward from any to $ipDmzServer in-if $ifWan out-if $ifDMZ proto tcp dport httpsiptables -I FORWARD -s 0/0 -d $ipDmzServer -i $ifWan -o $ifDMS -p tcp --destination-port https -j ACCEPT
И где разница, кроме того что синтаксис другой ...
>> allow forward from any to $ipDmzServer in-if $ifWan out-if $ifDMZ proto tcp dport https
>
>iptables -I FORWARD -s 0/0 -d $ipDmzServer -i $ifWan -o $ifDMS -p
>tcp --destination-port https -j ACCEPT
>
>И где разница, кроме того что синтаксис другой ...Я бы не делал акцент на синтаксисе. В данном случае ее действительно практически нет. На страничке проекта альтернативный синтаксис даже не вынесен в "возможности" (features), поскольку это далеко не главное.
Рассмотрите эту строчку в контексте с другими, ведь правил на фаере как правило больше одного. А теперь представте что правил там несколько тысяч. Или десятков тысяч. Желание сгруппировать их, снабдить комментариями, или хотя-бы просто сократить объем анализируемой при просмотре информации возникнет очень быстро. И группировка, скорее всего, будет производиться по влиянию правил на доступность конкретных сетевых приложений. Вот мы уже вплотную подошли к сервис-ориентированности.
Расширим рамки - вы в организации не единственный сисадмин, и у вас далеко не один сервер/маршрутизатор. По мере развития все равно или поздно разрабатывают свои внутренние стандарты, или, если им повезет, следуют ранее принятым - как оформлять комментарии, как группировать правила, какие правила использовать в той или иной ситуации, какие использовать переменные, где инициализировать их значения и т.п. И теперь вы уже не вольный художник с гибким и мощным инструментом, вы заложник стандартов. И что-бы им следовать и не ошибаться, вы сами-же начнете разрабатывать макросы или функции, заменяющие одинаковые последовательности команд одним вызовом и сводящие к минимуму объем набиваемого текста. Вы вплотную подошли к упрощению синтаксиса.
Возмем штатную рабочую ситуацию - необходимо изменить настройки фаервола на маршрутизаторе. В простейшем случае (а именно так поступает большинство) вы находите в своем скрипте с последовательностью команд iptables нужные комменты, добавляете или модифицируете правила, и перезапускаете скрипт. Сброс цепочек, применение полиси, пошли добавляться правила... Через некоторое время пакеты снова забегали. Никто из работающих через маршрутизатор практически ничего и не заметил. Ну, тормознул браузер. Ну, аська переконнектилась. Хотя, если вы ошиблись, и скрипт не отработал сразу без ошибок, времени потребуется немного больше и кое-кто может занервничать... А теперь вспомним что правил много (очень много!), а клиентов, работающих через маршрутизатор, ненамногим меньше. И они очень нетерпеливые. И в случае перебоя со связью на вас обрушивается шквал телефонных звонков, потому что вы еще и служба поддержки к тому-же. Через пару промахов вас вызовет к себе ваш руководитель и вставит чопик. Который ему достанется от его руководителя. И что-бы этого избежать в будущем вы задумаетесь - как быстро и аккуратно вносить точечные изменения в работающий фаер, минимизируя последствия (читай - простой) от допущенной ошибки (а человеческий фактор еще никто не отменял). При достаточно серъезном подходе к должностным обязанностям вы быстро обрастете своими-же "обертками".
Предполагаю, что все создатели каких-либо "оберток" начинали с этого-же. Не от праздного любобытства разрабатывались упомянутые здесь shorewall'ы и ufw'ы. Все от нужды... :)
Несогласен. Давайте разберемся в схеме построений правил. Бывает статический набор правил, обычно задается самим сисадмином, и динамический - строится по каким то внешним раздражителям, состояниям счета у пользователя, состоянием сервиса и т.д. Как привязать эту схему к динамике - я честно говоря не представляю.
Что же делается в статике - я могу рассказть. Если мне необходимо провести изменения в живом наборе правил - я меняю именно живой набор правил, какие то правила удаляю, какието добавляю, какието меняю. Все правила начинают работать немедленно и я сразу вижу изменения в работе. Только после того как задача выполнена и пакеты побежали по новой схеме я их сохраняю. Фушкционал iptables-save уже давно реализован и только он реализует полную и правильную сохранность правил. Конечно есть вариант что save неиспользуется, а все правила написаны в неком промежуточном файле с последовательным вызовом iptables. В таком случае стоит задуматься о изменении механизма хранения правил, а не о его модернизации.
И еще один момент. Если я как нерадивый сисадмин буду получать он начальства нагоняи за свои ошибки - это обидно. Но если я буду получать тоже самое, но за ошибки которые потенциально содержатся в сторонней программе - так мне и надо. А представим ситуацию когда в этой программе просто нехватит функционала...
>Фушкционал iptables-save уже давно реализован и только
>он реализует полную и правильную сохранность правил. Конечно есть вариант что
>save неиспользуется, а все правила написаны в неком промежуточном файле с
>последовательным вызовом iptables. В таком случае стоит задуматься о изменении механизма
>хранения правил, а не о его модернизации.
>И еще один момент. Если я как нерадивый сисадмин буду получать он
>начальства нагоняи за свои ошибки - это обидно. Но если я
>буду получать тоже самое, но за ошибки которые потенциально содержатся в
>сторонней программе - так мне и надо. А представим ситуацию когда
>в этой программе просто нехватит функционала...Волков бояться - в лес не ходить :) В принципе, никто не позиционирует никакую "обертку" как замену iptables - любая "обертка" это ведь только надстройка. Кто запретит вам использовать команды iptables напрямую? Я сам, к примеру, часто так и делаю. Те-же сервисы для flex-fw описываю командами iptables. В этом случае flex-fw предоставляет удобные возможности по быстрой блокировке/разрешению трафика минимизируя ручные манипуляции, и как следствие - вероятность ошибки. Достаточно запустить или остановить сервис flex-fw одной командой. И она будет одинаковой для всех, обслуживаемых у вас, маршрутизаторов.
Может это для вас и незначительно, но для меня было весьма критично - администрированием занималось несколько специалистов, каждый со своими "замутами", стилем работы и опытом...Я думаю что продолжать в том-же духе можно долго, и у каждого будут свои аргументы, опирающиеся на его личный опыт. Но, увы, это чужой опыт. Пока сам не почувствуешь необходимость изменений - они тебе не нужны :)
Вот такая нужна!!!http://i15.tinypic.com/4kemw0k.jpg
Только не куча г..на, на PHP/Pyton/Apache/MySQL/RRDtools/iptables2 ядрённых модуля - для слежения и управления.
1 библиотека для парсинга ввода/вывода и GUI
1 демон для сервера, логирования, статистики.
1 API для плугинов.
Туева хуча плугинов... (напр. для запуска USB-кофемолки при обнаружении спец пакета) :)
А вы конфиг, который это чудо делает, пытались прочитать, и главное, понять?
>А вы конфиг, который это чудо делает, пытались прочитать, и главное, понять?
>У Сисок, два понятия управлением фраерволом - через ГУЙ и КЛИ,
90% населения серверных хватает ГУЯ, и лишь 10% ШайтанБубен-IOSАдмины.
Кстати, от конфига фаервола на иптаблес, народ тоже в обморок падал...
>Кстати, от конфига фаервола на иптаблес, народ тоже в обморок падал...Та самая "блондинка на лексусе" из #36? Бе-есчеловечный!! Ж)
>>Кстати, от конфига фаервола на иптаблес, народ тоже в обморок падал...
>
>Та самая "блондинка на лексусе" из #36? Бе-есчеловечный!! Ж)А так же:
аппроксимация и экстраполяция- это какие-то виды эпиляции...
интерференция и дифракция - это что-то политическое
Впадают в глубокий экстаз от Дифференциальное уравнение высшего порядка... а-а-а-а
Значит этих 90% админов нельзя подпускать к Сискам, ибо в руках таких админов очень надежные железки превращаются в дыры.
Честно говоря совершенно не понял цели данной надстройки. Правила построения файервола - это очень сисадминская задача, требующего понимания и щепетильности. Всяческое упрощение приведет к появлению недосмотров и в итоге дырок. И опять же человек, ВРИО сисадмина, который не проверил фаерволл!!! зря получает зарплату.
А теперь по самой программе. Вся сила и прелесть iptables именно в его цепочках и таблицах. Т.е. если человеку надо создать собственную цепочку - то надо очень плотно поработать с этой программой, не лучше ли это время потратить на изучение самого iptables? Второй момент: дополнительные модули. Их много и с самым разным функционалом и опциями, боюсь что в полном объеме поддержку всех модулей реализовать просто нереально. Значит останутся места где надо будет доделывать функционал фаервола руками, а это опять же дыра в защите.
Я лично видел негатиный результат от использования некоторыми сисадминами надстройки shorewall, народ просто сидел на упрощенной схеме и даже не пытался разобраться. Я так считаю если общее количество правил не прывашает 50-100 строк - то все они легко читаются и настраиваюстя штатными средствами. А если количество правил больше, и чем больше тем это актуальней - то ручная правка и тщательная проверка крайне необходима.
ИМХО: людям которые мне показали эту ссылку я нерекомендую использовать данную прогу. Обычные проблемы у новичков - набор правил для предотвращения атак с внешнего интерфейса, есть масса примеров с готовыми правилами описывающую данную ситуацию. А у специалистов - я думаю вывод будет простой.
>Обычные проблемы у новичков - набор правил для предотвращения атак с
>внешнего интерфейса, есть масса примеров с готовыми правилами описывающую данную ситуацию.
>А у специалистов - я думаю вывод будет простой.Да как бы и не на новичков все это ориентировано... Назвать себя новичком язык не поворачивается. Лично мне в работе подобный инструмент помогает. Если он поможет еще хотя бы одному человеку кроме меня - значит проект опубликован не зря :)
Думаю, что способ заставить людей изучить что-либо, отняв у них более простые способы, работать не будет. Разумеется "глубины" можно изучить самостоятельно, ощутив недостаток функционала/гибкости, но некоторым и существующего будет в достатке.
Проект скорее "for fun", но как и все остальное, имеет право на существование.
>Честно говоря совершенно не понял цели данной надстройки.Цель - управлять на уровне сервисов а не пакетов. Типичная задача автоматизации управления сетью.
Вот вы тут рассуждаете - десятки-сотни файерволов, команда админов, тысячи клиентов вроде как вынудили написать "обёртку", но я не понимаю, почему в подобного масштаба организации не используются решения уровня Enterprise, например тот же CheckPoint? Эти ребята изобрели stateful FW, и делают замечательные файерволы, экономя время и нервы (а в итоге и деньги) подразделениям поддержки сетевой инфраструктуры. Для сетей попроще отлично работают файерволы Cisco, например. К чему все эти красноглазые велосипеды и программисткий зуд? Я понимаю в конторках на 100-300 человек с парой филиалов, но в крупных компаниях допускать самоделки? Ну напишет человек мега-тулзу, всем хорошо и бесплатно, потом он уволился, и понемногу начнутся проблемы - там не так сработало, тут не хватило функционала для такой-то задачки и т.п. Я уже молчу о жизненном цикле ПО, если автор забьет на разработку через годок, а контора уже вляпалась по самое небалуйся... Страшно, товарищи!
Вы наверно прямиком с cisco.com к нам заглянули? =) "тыщи" маршрутизаторов на базе pc, как правило у интернет-провайдеров вторичного рынка небольших городов, пиксы, чекпоинты и асы, им не подходят, да и по цене они "не свезут". Может быть и есть компании подобного профиля куда без ITIL не берут, но они явно все внутри МКАД. ))
Фраза "К чему все эти красноглазые велосипеды и программисткий зуд?", может быть смело опубликована в обсуждении чуть не каждой новости этого ресурса.
