Вышел (http://lurker.clamav.net/message/20100920.182819.5c96ca5c.en...) корректирующий релиз свободного антивирусного пакета ClamAV 0.96.3 (http://www.clamav.net/) в котором внесено 26 изменений (http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob_plain...). В представленном обновлении устранена опасная уязвимость (http://www.opennet.me/opennews/art.shtml?num=28021) во встроенном распаковщике сжатых данных в формате bzip2, позволяющая добиться выполнения кода при проверке специально подготовленного файла. Также отмечается исправление ряда проблем в PDF-парсере, которые судя по всему также могут привести к проблемам безопасности (исправлена ошибка проверки на допустимость границ параметров).URL: http://lurker.clamav.net/message/20100920.182819.5c96ca5c.en...
Новость: http://www.opennet.me/opennews/art.shtml?num=28070
Интересно, а на каком месте по эффективности он стоит по отношению к своим коммерческим аналогам? А если он им перестанет уступать то тогда может ли это сбить цены на этом рынке?
Сигнатуры там отличные, а вот движок крайне сырой, медленный. Например, .avi файл он проверяет тупо читая его от начала до конца.
это известный тролль с глупыми вопросами. пора уже запомнить, что он просто издевается.
Фиг вам, как платили так и будете платить под своей виндой. За файрволы, антивирусы, антиспайварь и какой там еще антигеморрой :). И что характерно - сколько ни заплати, а ничего сравнимого по функционалу с айпитаблесом под винду ... нет.
Иногда лучше жевать - чем говорить. Хотя тебе лишний раз ламерские (да да - не чайниковские, а ламерские - ибо желания изучать вопрос у тебя нету)ipfw for win32 будет получше чем кривые iptables.
>...ipfw for win32Это что еще за изврат такой?
Судя по описанию, это аналог ipfw из FreeBSD. Дак вот FreeBSD-шный ipfw - это самый убогий фаерволл под unix-системами с которым я только сталкивался :). Чрезвычайно медленный, всё в одной таблице, прилагаемые средства для NAT-ирования вообще съедают весь CPU при прохождении всего 30Mibps на достаточно нехилом компьютере для роутера, да и к тому же ничерта не умеет (если сравнивать, например, с iptables). Единственное почему я иногда использую ipfw, это потому что через него осуществляется работа с DUMMYNET.Но это лично моё скромное мнение о нём. Самым мощным фаерволлом на мой взгляд является iptables, а под *BSD надо использовать pf.
Вызывающе неверная информация.
Если делать NAT через ng_nat или ipfw nat проц будет жраться как минимум не больше, чем под pf.
>Вызывающе неверная информация.
>Если делать NAT через ng_nat или ipfw nat проц будет жраться как
>минимум не больше, чем под pf.Хм, не припомню этого ng_nat на FreeBSD5, где я из-за тормознутости natd я был вынужден полюбить сначала ipnat, а потом собственно pf. Извиняюсь, если мои текущие знания уже не актуальны. Но даже данная поправка не меняет того, что единственным плюсом ipfw является лишь то, что освоиться в нём чрезвычайно просто, а в остальном одни минусы. Ещё раз подчеркну, что это всё лишь по моему скромному мнению.
Притом, natd - был не единственной причиной перехода на pf. Был другой роутер, который не занимался NAT-ированием, зато выполнял множество других функций firewall-а. Тоже при определённом потоке перестал справляться, как стоило бы. При переходе на pf, заставив его выполнять те же функции, проблема изчезла. Но тут я согласен, что пример некорректен :)
P.S. Вообще мой начальный пост был направлен против фразы "кривой iptables", когда на замену представили "ipfw". Я извиняюсь, если дал слишком большую волю эмоциям. Да, я не люблю ipfw, но был не прав высказав это таким образом. Просто я не встречал более мощного firewall-а чем iptables, зато встречал множество людей, которые его не осилили и поэтому на него ругались.
>Хм, не припомню этого ng_nat на FreeBSD5, где я из-за тормознутости natd
>я был вынужден полюбить сначала ipnat, а потом собственно pf.ng_nat действительно появился в 6.0. До этого, да, только ipnat/pf для ната на уровне ядра.
>Но даже данная поправка
>не меняет того, что единственным плюсом ipfw является лишь то, что
>освоиться в нём чрезвычайно просто,Это уже немало :-)
>Просто я не встречал более мощного firewall-а чем
>iptables, зато встречал множество людей, которые его не осилили и поэтому
>на него ругались.Возможно, это так...
Просто у меня пока не возникало потребностей, где бы можно было использовать мощь iptables, а порог вхождения действительно высоковат...
Если поделитесь примерами, что на ipfw решить невозможно/сложно, а на iptables возможно/проще, буду благодарен. Без иронии.
>[оверквотинг удален]
>>я был вынужден полюбить сначала ipnat, а потом собственно pf.
>
>ng_nat действительно появился в 6.0. До этого, да, только ipnat/pf для ната
>на уровне ядра.
>
>>Но даже данная поправка
>>не меняет того, что единственным плюсом ipfw является лишь то, что
>>освоиться в нём чрезвычайно просто,
>
>Это уже немало :-)_IMHO_, если освоиться с iptables, с ним работать намного проще.
>
>>Просто я не встречал более мощного firewall-а чем
>>iptables, зато встречал множество людей, которые его не осилили и поэтому
>>на него ругались.
>
>Возможно, это так...
>Просто у меня пока не возникало потребностей, где бы можно было использовать
>мощь iptables, а порог вхождения действительно высоковат...
>Если поделитесь примерами, что на ipfw решить невозможно/сложно, а на iptables возможно/проще,
>буду благодарен. Без иронии.Ну, port-knocking например. В iptables достаточно одного лишь recent для его реализации в 2 строчки, а в ipfw я могу представить его реализацию только с использованием внешних утилит. Хотя, возможно, я ещё много чего не знаю о современном ipfw, конечно...
Ну или если хочется сделать VPN-роутер предоставляющий доступ в Интернет, который автоматически банит спамеров (речь про спам по SMTP инфицированными компьютерами). В iptables данная автоматика делается в 3 строки используя recent и hashlimit. Как сделать в ipfw я тоже себе не представляю.
Или даже самый элементарный "ttl-set", что вообще уж проще некуда. Где это в ipfw?
На самом деле, когда есть iptables, даже fail2ban нафиг не нужен, обычно :)
Примеров тонны. И не просто эзотерические примеры, а тех приёмы, которые мне уже пригождались в тех или иных целях.
И я не пытаюсь доказать, что iptables лучше. Просто призываю одного автора не называть iptables кривым, предлагая взамен ipfw.
> Ну, port-knocking например. В iptables достаточно одного лишь recent для его реализации
> в 2 строчки, а в ipfw я могу представить его реализацию
> только с использованием внешних утилит.Да вроде, можно.
ipfw count log ...
потом syslog через syslog.conf запускает скрипт, который выкусывает IP из лога и открывает правило через ipfw table, например.
Народ даже делал, чтобы открывался доступ только после пинга с опредленным размером пакета. IMHO удобнее, чем port-knocking, т.к. некоторые дистрибутивы Linux уже идут без telnet по умолчанию. (Мне в Федоре приходилось ставить через yum)> Или даже самый элементарный "ttl-set", что вообще уж проще некуда. Где это
> в ipfw?ng_patch(4), недавно закоммитили :-)
http://nuclight.livejournal.com/126002.html
Кстати, netgraph реально мощная штука. Хотя это и набор инструментов, а не готовое решение, но позволяет делать с сетью почти что угодно.
>> Ну, port-knocking например. В iptables достаточно одного лишь recent для его реализации
>> в 2 строчки, а в ipfw я могу представить его реализацию
>> только с использованием внешних утилит.
> Да вроде, можно.
> ipfw count log ...
> потом syslog через syslog.conf запускает скрипт, который выкусывает IP из лога и
> открывает правило через ipfw table, например.Ну дак я же говорил про реализацию на уровне фаерволла, а продложенное вами работает лишь с использованием внешних утилит, а именно:
1.) syslog
2.) скриптНе кажется что это слишком костыльно? Тем более предложенная реализация работает по косвенным признакам - читает записи в логах, что вообще говоря опять же костыль, по моему личному мнению. ipfw своими внутренними средствами так легко и просто добавив две строчки не в жизнь не даст столь простую и, IMHO, полезную возможность. Это ведь был пример того, что в ipfw невозможно/трудно сделать, а именно невозможно на уровне самого фаерволла и "трудно" с использованием внешних утилит. Когда как в iptables:
-t mangle -A INPUT -p tcp --dport 55655 -m recent --set --name openssh
-t filter -A INPUT -p tcp --dport 22 -m recent --rcheck --name openssh -j ACCEPT
и всё ;)> Народ даже делал, чтобы открывался доступ только после пинга с опредленным размером
> пакета. IMHO удобнее, чем port-knocking, т.к. некоторые дистрибутивяы Linux уже идут
> без telnet по умолчанию. (Мне в Федоре приходилось ставить через yum)Ой, а постучать можно хоть тем же yum-ом, указав переменную http_proxy на этот самый порт, если конечно yum понимает эту переменную. Ну или программой ssh-клиентом, указав флаг "-p".
>> Или даже самый элементарный "ttl-set", что вообще уж проще некуда. Где это
>> в ipfw?
> ng_patch(4), недавно закоммитили :-)
> http://nuclight.livejournal.com/126002.html
> Кстати, netgraph реально мощная штука. Хотя это и набор инструментов, а не
> готовое решение, но позволяет делать с сетью почти что угодно.Ну это хорошо что закоммитили, но вам самому то не смешно, что закоммитили лишь недавно :). Хотя вообще я рад, что наконец-то ipfw обрастает всякими вкусностями.
Если бы в ipfw были отдельные таблицы правил как в iptables на prerouting, input, forward, output, postrouting и добавили бы аналоги хотя бы recent, hashlimit, length, statistics (хотя "prob" впринципе заменяет один из режимов работы statistics), time, string и u32, то в добавок с учётом последних изменений, которые надо признать совсем я недавние, ipfw стал бы для меня почти настолько же полезным, как и iptables. :)
Притом я не говорю про всякие другие на мой взгляд полезные возможности вроде tos, tee, mirror, tcpmss или, например, cluster, лишь потому, что я ими пока что ниразу не пользовался. Но, напрмиер, лишь самая идея с "led" у iptables просто душу греет :)
> Не кажется что это слишком костыльно?Кажется. Только еще более костыльной мне кажется сама идея порт-кнокинга :-)
Проще перевешать sshd на другой порт.
%%да, потребности в колбасе нет%%> Ну это хорошо что закоммитили, но вам самому то не смешно, что
> закоммитили лишь недавно :).Так патчи давно ходили.
Просто у меня не было потребности менять ttl.> Если бы в ipfw были отдельные таблицы правил как в iptables на
Честно говоря, вот это разделение на таблицы правил мне кажется неоправданным усложнением.
Хотя, с iptables я сталкиваюсь больше по необходимости, может и есть в них какая-то логика...> prerouting, input, forward, output, postrouting и добавили бы аналоги хотя бы
> recent, hashlimit, length, statistics (хотя "prob" впринципе заменяет один из режимов
> работы statistics), time, string и u32, то в добавок с учётом
> последних изменений, которые надо признать совсем я недавние, ipfw стал бы
> для меня почти настолько же полезным, как и iptables. :)Аналоги recent и hashlomit есть, см. секцию STATEFUL FIREWALL
length - iplen
А какое-то подобие Lookup Tables в iptables есть?
>> Не кажется что это слишком костыльно?
> Кажется. Только еще более костыльной мне кажется сама идея порт-кнокинга :-)
> Проще перевешать sshd на другой порт.
> %%да, потребности в колбасе нет%%Ну, я portknocking применяю только для обхода случайного бана. Т.е. когда настраиваю фаерволл удалённо, port-knocking может быть очень полезным и геморроиться с парсингом логов - вообще никакого желания ради такой мелочи :)
>[оверквотинг удален]
> Честно говоря, вот это разделение на таблицы правил мне кажется неоправданным усложнением.
> Хотя, с iptables я сталкиваюсь больше по необходимости, может и есть в
> них какая-то логика...
>> prerouting, input, forward, output, postrouting и добавили бы аналоги хотя бы
>> recent, hashlimit, length, statistics (хотя "prob" впринципе заменяет один из режимов
>> работы statistics), time, string и u32, то в добавок с учётом
>> последних изменений, которые надо признать совсем я недавние, ipfw стал бы
>> для меня почти настолько же полезным, как и iptables. :)
> Аналоги recent и hashlomit есть, см. секцию STATEFUL FIREWALL
> length - iplenВы как-то сильно унизили возможности hashlimit и recent. Например то, что продемонстрировал я с recent (а я могу ещё много чего надемонстрировать) с помощью лишь keep-state не реализовать. А по поводу hashlimit, я просто рекомендую прочесть что это такое и в чём его _принципиальное_ отличие от connlimit и limit.. Я так понял вы намекаете на ipfw-шный "limit", который является сильно упрощённым вариантом "connlimit" в iptables (например несколькоступеньчатая работа с масками, порядком эффективнее помогает против DDoS, в то время, как ipfw умеет работать только по /32), а аналогов hashlimit, даже упрощённых, я в ipfw не припоминаю.
> А какое-то подобие Lookup Tables в iptables есть?
Ну, во-первых в iptables есть цепочки, которые, к сожелению, я так понял вам не очень нравятся. А во-вторых для особых случаев всегда есть "ipset" (http://www.opennet.me/prog/info/2942.shtml).
> Ну, я portknocking применяю только для обхода случайного бана. Т.е. когда настраиваю
> фаерволл удалённо, port-knocking может быть очень полезным и геморроиться с парсингом
> логов - вообще никакого желания ради такой мелочи :)После того, как я перевешал sshd на другой порт, проблема распухания лога от перебора паролей перестала меня беспокоить безо всякого фаервола. А если пароль 123, то и port-knocking не спасет.
> Вы как-то сильно унизили возможности hashlimit и recent. Например то, что продемонстрировал
Это не окупает усложнения, которое вносит iptables. Слишком редко это нужно. А когда нужно можно и с syslog заморочиться.
>> А какое-то подобие Lookup Tables в iptables есть?
> Ну, во-первых в iptables есть цепочки, которые, к сожелению, я так понял
> вам не очень нравятся. А во-вторых для особых случаев всегда есть
> "ipset" (http://www.opennet.me/prog/info/2942.shtml).Костыль же.
>> Ну, я portknocking применяю только для обхода случайного бана. Т.е. когда настраиваю
>> фаерволл удалённо, port-knocking может быть очень полезным и геморроиться с парсингом
>> логов - вообще никакого желания ради такой мелочи :)
> После того, как я перевешал sshd на другой порт, проблема распухания лога
> от перебора паролей перестала меня беспокоить безо всякого фаервола. А если
> пароль 123, то и port-knocking не спасет.Я вообще-то не про брут-форс, а про безопасную настройку фаерволла (т.е. чтобы ssh не отвалился). Хотя если уж на то пошло, то перебора паролей это тоже касается :)
>> Вы как-то сильно унизили возможности hashlimit и recent. Например то, что продемонстрировал
> Это не окупает усложнения, которое вносит iptables. Слишком редко это нужно. А
> когда нужно можно и с syslog заморочиться.Честно сказать, я не понимаю про какие усложнения речь. :)
Это как тензорные обозначения взамен векторным во многих областях физики. Надо не полениться и один раз въехать, что относительно просто, и потом будет уже проще преобразовывать различные выражения, чем то было в векторных обозначениях. Например представляете себе кванты в векторных обозначениях? IMHO, кошмар :)Т.е. другими словами, лично мне субъективно кажется, что с iptables проще работать, чем с ipfw при разумно достатоно большом, но одинаковом опыте работы с тем и другим.
И ещё одно... Я считаю, что очень даже окупает, даже если считать данную разность интерфейсов усложнением :)
>>> А какое-то подобие Lookup Tables в iptables есть?
>> Ну, во-первых в iptables есть цепочки, которые, к сожелению, я так понял
>> вам не очень нравятся. А во-вторых для особых случаев всегда есть
>> "ipset" (http://www.opennet.me/prog/info/2942.shtml).
> Костыль же.Что костыль? Использование "ipset"? Это, IMHO, примерно такой же "костыль", как использование утилиты "ipfw" для настройки фаерволла ipfw. Другими словами, я не понимаю в чём костыль. ifconfig для настройки интерфейсов, sysctl для управления переменными системы, iptables для настройки правил фаерволла, ipset для настройки IP set-ов. Не понимаю в чём проблема. Вы так говорите, как будто ipset - это какая-то отдельная утилита, которая никак не касается проекта netfilter (http://netfilter.org/). Вообщем, было бы неплохо, если бы вы пояснили в чём, собственно, "костыль". ;)
> Я вообще-то не про брут-форс, а про безопасную настройку фаерволла (т.е. чтобы
> ssh не отвалился). Хотя если уж на то пошло, то перебора
> паролей это тоже касается :)Если накосячить с настройкой фаервола, то и порт-кнокинг не поможет. А если фаерволом не закрывать ssh, то порт-кнокинг и не нужен.
> Честно сказать, я не понимаю про какие усложнения речь. :)
Неочевидные эти цепочки INPUT,OUTPUT, PREROUTING, POSTROUTING etc отсутствие номеров правил по умолчанию и т.п.
> Это как тензорные обозначения взамен векторным во многих областях физики. Надо не
> полениться и один раз въехать, что относительно просто, и потом будет
> уже проще преобразовывать различные выражения,Зачем, если и так все работает? У меня есть другие задачи, на которые надо тратить время, чем еще штудировать всякие неочевидные премудрости iptables, для которых надо еще и линукс громоздить.
> Т.е. другими словами, лично мне субъективно кажется, что с iptables проще работать,
> чем с ipfw при разумно достатоно большом, но одинаковом опыте работы
> с тем и другим.Не согласен.
> И ещё одно... Я считаю, что очень даже окупает, даже если считать
> данную разность интерфейсов усложнением :)Аналогично, не согласен.
>>>> А какое-то подобие Lookup Tables в iptables есть?
>>> Ну, во-первых в iptables есть цепочки, которые, к сожелению, я так понял
>>> вам не очень нравятся. А во-вторых для особых случаев всегда есть
>>> "ipset" (http://www.opennet.me/prog/info/2942.shtml).
>> Костыль же.
> Что костыль? Использование "ipset"? Это, IMHO, примерно такой же "костыль", как использованиеНу да. В стандартную поставку той же федоры не входит.
>> Я вообще-то не про брут-форс, а про безопасную настройку фаерволла (т.е. чтобы
>> ssh не отвалился). Хотя если уж на то пошло, то перебора
>> паролей это тоже касается :)
> Если накосячить с настройкой фаервола, то и порт-кнокинг не поможет. А если
> фаерволом не закрывать ssh, то порт-кнокинг и не нужен.Ну почему, просто держишь в правилах фаерволла в начале port-knocking, а потом всё остальное и балуйся сколько хочешь :)
>> Честно сказать, я не понимаю про какие усложнения речь. :)
> Неочевидные эти цепочки INPUT,OUTPUT, PREROUTING, POSTROUTING etc отсутствие номеров
> правил по умолчанию и т.п.Очень даже очевидные, IMHO. Один раз посмотреть на http://upload.wikimedia.org/wikipedia/ru/a/ad/Netfilter-diag... и сразу всё понятно, IMHO
>> Это как тензорные обозначения взамен векторным во многих областях физики. Надо не
>> полениться и один раз въехать, что относительно просто, и потом будет
>> уже проще преобразовывать различные выражения,
> Зачем, если и так все работает? У меня есть другие задачи, на
> которые надо тратить время, чем еще штудировать всякие неочевидные премудрости iptables,
> для которых надо еще и линукс громоздить.Я ж только что пояснил. Один раз потратить время, ради того чтобы в будущем его тратить ещё меньше, чем предполагалось изначально.
>> Т.е. другими словами, лично мне субъективно кажется, что с iptables проще работать,
>> чем с ipfw при разумно достатоно большом, но одинаковом опыте работы
>> с тем и другим.
> Не согласен.Имеете право. Я когда-то достаточно долго работал с ipfw, после чего перешёл на pf, продолжая очень не любить и не хотеть изучать iptables из-за его перенаграмождённости. Однако всего лишь раз я когда-то уже не помню когда был вынужден настроить чрезвычайно нетривиальный роутер на linux и сразу со всем освоился и полюбил iptables.
>> И ещё одно... Я считаю, что очень даже окупает, даже если считать
>> данную разность интерфейсов усложнением :)
> Аналогично, не согласен.
>>>>> А какое-то подобие Lookup Tables в iptables есть?
>>>> Ну, во-первых в iptables есть цепочки, которые, к сожелению, я так понял
>>>> вам не очень нравятся. А во-вторых для особых случаев всегда есть
>>>> "ipset" (http://www.opennet.me/prog/info/2942.shtml).
>>> Костыль же.
>> Что костыль? Использование "ipset"? Это, IMHO, примерно такой же "костыль", как использование
> Ну да. В стандартную поставку той же федоры не входит.Ну есть дистрибутивы, где и утилита "iptables" не поставляется по умолчанию. Лично я вообще предпочитаю устанавливать систему по минимализму, в потом уже доставлять всё, что мне нужно (iptables, netcat, gcc, make, traceroute, tcpdump и т.п.). Утрируя, просто Спевак и его ребята (или уже не Спевак?) сочли, что на средний десктоп незачем ставить ipset по умолчанию.
И ещё одно, если посмотреть на debian, то та же утилита "iptables" идёт естественно отдельным пакетом:
$ dpkg -l | grep iptables
ii iptables 1.4.8-3 administration tools for packet filtering and NAT
И если теперь прочесть описание для ipset и сравнить с iptables, то лично я не нахожу принципиальной разницы, которая делает использование утилиты "ipset" - костылём, когда как использование утилиты "iptables" - не костыль.
$ dpkg -l | grep ipset
ii ipset 2.5.0-1 administration tool for kernel IP setsПо вашей логике, если вспомнить все существующие дистрибутивы, то использовать linux - это вообще всегда "костыль" ;)
> Ну почему, просто держишь в правилах фаерволла в начале port-knocking, а потом
> всё остальное и балуйся сколько хочешь :)И любой залетный дятел со сканером портов отключает весь фаерволл на раз-два.
Отказать.> Очень даже очевидные, IMHO. Один раз посмотреть на http://upload.wikimedia.org/wikipedia/ru/a/ad/Netfilter-diag...
> и сразу всё понятно, IMHOНет.
> Я ж только что пояснил. Один раз потратить время, ради того чтобы
> в будущем его тратить ещё меньше, чем предполагалось изначально.Куда уж еще меньше?
> сразу со всем освоился и полюбил iptables.
Ну и на здоровье. Я вот вряд ли его полюблю.
Ибо монстроид.>>> Что костыль? Использование "ipset"? Это, IMHO, примерно такой же "костыль", как использование
>> Ну да. В стандартную поставку той же федоры не входит.
> Ну есть дистрибутивы, где и утилита "iptables" не поставляется по умолчанию.[root@spring alex]# yum list iptables
Загружены модули: presto
Установленные пакеты
iptables.i686 1.4.7-2.fc13 @anaconda-InstallationRepo-201005130056.i386
[root@spring alex]# yum list \*ipset\*
Загружены модули: presto
Ошибка: Совпадений среди пакетов не найдено
[root@spring alex]# grep -l enabled=1 /etc/yum.repos.d/*.repo
/etc/yum.repos.d/adobe-linux-i386.repo
/etc/yum.repos.d/fedora.repo
/etc/yum.repos.d/fedora-updates.repo
/etc/yum.repos.d/rpmfusion-free.repo
/etc/yum.repos.d/rpmfusion-free-updates.repo
/etc/yum.repos.d/rpmfusion-nonfree.repo
/etc/yum.repos.d/rpmfusion-nonfree-updates.repo./configure
make
make install?
>> Ну почему, просто держишь в правилах фаерволла в начале port-knocking, а потом
>> всё остальное и балуйся сколько хочешь :)
> И любой залетный дятел со сканером портов отключает весь фаерволл на раз-два.
> Отказать.Во-первых не весь фаерволл, а только один порт и только для одного клиента. Во-вторых у меня уже есть готовая комбинация port-knocking-а, открывающая порт только на 20 секунд максимум раз в час. К тому же в этой комбинации при попытке стучаться на соседние порты клиент банится на этот самый час, поэтому сканер портов скорее приведёт к временному бану, а не наоборот.
>> Очень даже очевидные, IMHO. Один раз посмотреть на http://upload.wikimedia.org/wikipedia/ru/a/ad/Netfilter-diag...
>> и сразу всё понятно, IMHO
> Нет.Ну как знаете :)
>> Я ж только что пояснил. Один раз потратить время, ради того чтобы
>> в будущем его тратить ещё меньше, чем предполагалось изначально.
> Куда уж еще меньше?Ну, например, в iptables мне никогда не приходилось вручную разделять приходящий на, исходящий с и пересылаемый через сервер трафик. Когда как в ipfw при настройке шейпера приходилось всё это разделять (особенно когда используется прозрачный прокси, задача неприятным образом усложняется). Это мелочь конечно, но, как говорится, "с миру по нитке".
>> сразу со всем освоился и полюбил iptables.
> Ну и на здоровье. Я вот вряд ли его полюблю.
> Ибо монстроид.As you wish :)
>[оверквотинг удален]
> /etc/yum.repos.d/adobe-linux-i386.repo
> /etc/yum.repos.d/fedora.repo
> /etc/yum.repos.d/fedora-updates.repo
> /etc/yum.repos.d/rpmfusion-free.repo
> /etc/yum.repos.d/rpmfusion-free-updates.repo
> /etc/yum.repos.d/rpmfusion-nonfree.repo
> /etc/yum.repos.d/rpmfusion-nonfree-updates.repo
> ./configure
> make
> make install?Я fedora суммарно пользовался часа 2 от силы, поэтому не знаю. Однако попробуйте поискать что-нибудь вроде "*xiptables*". Мне интересно, выведет что-нибудь или нет :). Если выведет, то наверника ipset есть в данном пакете.
> Во-первых не весь фаерволл, а только один порт и только для одного
> клиента. Во-вторых у меня уже есть готовая комбинация port-knocking-а, открывающая порт
> только на 20 секунд максимум раз в час. К тому же
> в этой комбинации при попытке стучаться на соседние порты клиент банится
> на этот самый час, поэтому сканер портов скорее приведёт к временному
> бану, а не наоборот.Охотно верю. Но возникают следующие вопросы:
1. Оправдано ли такое усложнение в конкретном случае?
2. Не логичнее ли такой сложный функционал реализовать внешними средствами?> при настройке шейпера приходилось всё это разделять (особенно когда используется прозрачный
> прокси, задача неприятным образом усложняется). Это мелочь конечно, но, как говорится,
> "с миру по нитке".А зачем шейпить файерволлом прозрачный прокси, если в том же squid есть delay pools, которые справляются с этой задачей не в пример лучше и гибче?
>> Во-первых не весь фаерволл, а только один порт и только для одного
>> клиента. Во-вторых у меня уже есть готовая комбинация port-knocking-а, открывающая порт
>> только на 20 секунд максимум раз в час. К тому же
>> в этой комбинации при попытке стучаться на соседние порты клиент банится
>> на этот самый час, поэтому сканер портов скорее приведёт к временному
>> бану, а не наоборот.
> Охотно верю. Но возникают следующие вопросы:
> 1. Оправдано ли такое усложнение в конкретном случае?Ну есть готовая связки - копипасти сколько угодно. Кому как удобнее.
> 2. Не логичнее ли такой сложный функционал реализовать внешними средствами?
Не логичнее. В фаерволле всё делается элементарно, быстро и элегантно, и работает в полном kernel space.
Тем более внешние средства НИКАК не помогут, если допустил косяк в правилах фаерволла, про что мы собственно и упоминали. Разве что сброс фаерволла по кронтабу :)
>> при настройке шейпера приходилось всё это разделять (особенно когда используется прозрачный
>> прокси, задача неприятным образом усложняется). Это мелочь конечно, но, как говорится,
>> "с миру по нитке".
> А зачем шейпить файерволлом прозрачный прокси, если в том же squid есть
> delay pools, которые справляются с этой задачей не в пример лучше
> и гибче?Я что-то не понял, а остальной трафик (который идёт в обход прокси) вы предлагаете не шейпить? Я ж подчеркнул, что прокси прозрачный. Как раз частью усложнения было отделить трафик прокси, трафика пользователей с проксёй, трафик пользователей с интернетом в обход прокси, трафик прокси в интернет. В iptables же всё это находится в разных цепочках, поэтому ничего разделять и не надо, т.к. уже всё зарание разделено. Собственно именно из-за этого усложнения в iptables он кажется таким монструозным, AFAIK.
И что там с ipset, не нашёлся? :)
>> Охотно верю. Но возникают следующие вопросы:
>> 1. Оправдано ли такое усложнение в конкретном случае?
> Ну есть готовая связки - копипасти сколько угодно. Кому как удобнее.Да я понимаю... Но вот сам алгоритм "раз в час на двадцать секунд" и т.п. что-то мне кажется неоправданным усложнением. Я вот не закрываю ssh порт ничем и сплю спокойно.
>> 2. Не логичнее ли такой сложный функционал реализовать внешними средствами?
> Не логичнее. В фаерволле всё делается элементарно, быстро и элегантно, и работает
> в полном kernel space.Во-первых, не вижу преимуществ от kernel space (во внешних средствах тоже не на каждый пакет переключение контекстов происходит), а во-вторых, сомненеваюсь, что в iptables такая логика будет просто/быстро/элегантно реализована. А если я еще историю захочу где хранить, да между перезагрузками или еще что? Тоже iptables в структурах ядра сохранит?
> Тем более внешние средства НИКАК не помогут, если допустил косяк в правилах
> фаерволла, про что мы собственно и упоминали. Разве что сброс фаерволла
> по кронтабу :)А ничто не поможет, включая порт-кнокинг.
Кстати альтернатива порт-кнокингу:
allow tcp from any to me 22 via ${ext_if} (22 заменить по вкусу)>> А зачем шейпить файерволлом прозрачный прокси, если в том же squid есть
>> delay pools, которые справляются с этой задачей не в пример лучше
>> и гибче?
> Я что-то не понял, а остальной трафик (который идёт в обход прокси)
> вы предлагаете не шейпить?То, что через прокси - средствами прокси, то что в обход - средствами фаерволла.
> И что там с ipset, не нашёлся? :)
Нашелся.
Установка:
xtables-addons i686 1.28-1.fc13 rpmfusion-free-updates 103 k
Установка зависимостей:
kmod-xtables-addons-2.6.34.7-56.fc13.i686
i686 1.28-1.fc13.3 rpmfusion-free-updates 78 kТ.е. в официальном репозитории (rpmfusion - неофициальный) его нет, нужен специальний ядерный модуль, не вхлдящий в комплект, в общем явно не стандартный инструмент.
Бесполезно, ему явно уже ничего не поможет.
Тем более судя по его посту он просто не осилил прочитать в мане о несовместимости либалиаса с TSO. :)
>Бесполезно, ему явно уже ничего не поможет.
>Тем более судя по его посту он просто не осилил прочитать в
>мане о несовместимости либалиаса с TSO. :)Хорошая гипотеза, но ошибочная. Я гуглил и спрашивал знакомых на эту тему, советовали отключить TSO, и хорошего результата так и не добился. Просто машинка была не такая мощная, чтобы заниматься NAT-ированием в user-space.
>Если делать NAT через ng_nat или ipfw nat проц будет жраться как
>минимум не больше, чем под pf.Блин, покажите все это на win32? Очень интересно посмотреть на такой изврат :)
> Блин, покажите все это на win32? Очень интересно посмотреть на такой изврат
> :)Под win32 это никто и не обещал. И вообще, была портирована только утилита для настройки вендового фаервола, а не сам фаервол.
ipfw for win32 будет получше чем кривые iptables
------Как-то помню хотел по-быстрому прикрутить ipfw win32 как файрвол на входящих dialup соединениях для доступа в локальную сетку, так оказалось что он не может работать с транзитными пакетами(т.е. которые форвардятся). ИМХО у ipfw win32 возможности слишком убогие, чтоб сравнивать его с iptables.
>ipfw for win32 будет получше чем кривые iptables.Я на него когда-то смотрел когда искал приличный фаер - кривой он какой-то и глючный был. Порт был явно недопиленный. Сами таким и пользуйтесь а я для себя предпочту по возможности более нормальную систему и айпитаблес, который работает и умеет все что мне когда либо хотелось/требовалось от фаера и намного больше.
Вот только iptables там не хватало. Это как самокат с квадратными колесами и кучей расбросанных в разных местах мануалов о том как закруглить колеса, где смазать и как менять покрышки. Лучше уже ipfw или pf.
>колеса, где смазать и как менять покрышки. Лучше уже ipfw или pf.Ну, ipfw вроде как даже есть. Только мне не понравился ни разу - насколько я помню, работал криво/странно/глючно, будучи явно недопиленным когда я на него смотрел.
Начнем с того, что firewall любого рода (именно firewall) никак не поможет бороться с вирусней. Тем более нынче авторы вирусов все больше изощряются.Ну и конечно, любой вирусописатель будет только счастлив встретить владельца компа, который верит, что файрволл вирусы не пропускает :)
>Начнем с того, что firewall любого рода (именно firewall) никак не поможет
>бороться с вирусней.Почему же. Привожу контрпример: винды и мсбласт. На некоторые такие машины апдейты затыкающие дыру удавалось слить только после установки фаера, т.к. иначе винда вылетала по ошибке сервиса быстрее чем сливались апдейты. Что очень доставляло юзерам, надо сказать - при входе в интернет через считанные секунды система вылетает с ошибкой и пользоваться интернетом невозможно вообще :)
>Тем более нынче авторы вирусов все больше изощряются.
Факт. Но все-таки уменьшить последствия атаки или предотвратить некоторые типы атак может как раз файрвол. Поэтому юзать винды без фаервола - достаточно ссыкотно. А если допустим троян запустился но застрял на фаере и не смог пароли слить - атака отбита, не? А уж убитый пакет с мсбластом и вовсе откровенно отбивание вирья в прямом смысле слова :)
>Ну и конечно, любой вирусописатель будет только счастлив встретить владельца компа,
>который верит, что файрволл вирусы не пропускает :)Самое интересное что данный спич вполне себе валиден для самоходной заразы по типу мсбласта - там файрвол действительно это самое :). Разумеется это еще не гарантия что другие типы вирусов и троянов не пролезут.
>на каком месте по эффективности он стоит по отношению к своим коммерческим аналогам?Он там и рядом не валялся. Винлоки не ловит (только очень старючие), про новые супер-шняги типа Confikera вообще речь не идет...
Поделие...
Что ты хочешь, ведь базы обновляют сами пользователи :) Оперативность черепаховая :)
>Он там и рядом не валялся. Винлоки не ловит (только очень старючие),Так их и Касперский и Дрвеб, как правило, не ловят достаточно долго.
Справедливости ради, скажу, что по моему мнению, оперативность добавления сигнатур в clamav упала в последние годы. Но вот раньше, вирусы появлялись в нем зачастую быстрее, чем в коммерческих аналогах. Особенно те, что ходили по E-Mail
>Так их и Касперский и Дрвеб, как правило, не ловят достаточно долго.Более того - почему-то чтобы они начали ловит - заразу кто-то должен заметить и прислать. Исключением может быть разве что абстрактная ситуация когда антивирусописатели сами выпускают вирус заранее занеся его в свою базу :)
>Что ты хочешь, ведь базы обновляют сами пользователи :) Оперативность черепаховая :)Ага, только почему-то я касперу слал на анализ штуки которые он не ловит. Каспера тоже в поделия запишем? Ну тогда все антивирусы делятся на слабаков, бесполезняшки-имитаторы и поделия :)))
не собьет он цены, бесплатных антивирусов под винду, которые под линукс (для десктопа) стали делать целая куча и на цены это не влияет.
Война-то уж давно кончилась, а раненных, не прочитавших Столмана и путающих свободное с бесплатным, всё везут и везут... :/...а свобода всегда стоит дороже, чем бесплатные кандалы.
оно уже умеет убивать на лету обновления для винды?
