1.4, valfrom (?), 14:30, 26/12/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ключ -table в iptables-restore недавно нужен был, ток подумал и тут новость :)
| |
|
|
|
Часть нити удалена модератором |
|
5.10, fresco (??), 15:29, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо, нормально объяснили. По-больше б таких камментов на ОпенНете
| |
5.11, sHaggY_caT (??), 15:43, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
да, спасибо...
Интересно, почему под Линь только iptables?
А под бсд столько много фильтров?
Кстати, у Солярки есть API для пакетных фильтров?
| |
|
6.13, Andrew Kolchoogin (?), 16:08, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> да, спасибо...
> Интересно, почему под Линь только iptables?
Это неправда. Есть порт IP Filter под Linux.
> А под бсд столько много фильтров?
Потому, что они изначально не договорились, но обмениваются кодом.
Изначально был IP Firewall под BSDi. По его образу и подобию был сделан ipfw для FreeBSD. А для NetBSD Darren Reed (кстати, соавтор RFC на IRC :) написал IP Filter.
Потом IP Filter был спортирован под FreeBSD и OpenBSD. Потом Reed поменял лицензию, и Тео де Раадт, который, как обычно, хотел быть святее Папы Римского, вынес IP Filter из дерева исходников. А другой человек написал взамен PF.
> Кстати, у Солярки есть API для пакетных фильтров?
Нет. Но есть порт IP Filter для Solaris.
| |
|
7.17, Ананимуз (?), 16:54, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> да, спасибо...
> Интересно, почему под Линь только iptables?
> Это неправда. Есть порт IP Filter под Linux.
Это тот, который IP filter -> IP chains -> IP tables?
| |
|
|
5.12, demimurych (?), 15:45, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
>
>Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и
>Linux одинаково плохи.
>Дело в том, что и Linux, и *BSD разрабатывались для машин с
>MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать
Не совсем понял какое отношение это имеет к вопросу о
>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
мне показалось что вы говорили о задачах где решаются вопросы с сколько нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня где я ошибся.
| |
5.15, Аноним (-), 16:27, 26/12/2007 [^] [^^] [^^^] [ответить] | +/– | Сейчас железки без MMU - скорее экзотика Если лучше, то почему куда ни плюнь в... большой текст свёрнут, показать | |
|
|
7.19, Аноним (-), 17:29, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Пакетный фильтр в случае DoS не поможет, будь
>он хоть сто раз скалируемый. :)
ну 100kpps вполне реально получить на половине fast ethernet.
| |
|
|
9.48, Аноним (-), 10:20, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | ага, но остались ОС, в которых нет polling и которым от относительно небольших з... текст свёрнут, показать | |
|
|
7.115, nuclight (?), 22:18, 30/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>>> Слишком много точек входа в ядро, код перегружен и глючит.
>> Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего
>> не умеет PF.
>
> PF _отлично_ скалируется на SMP. Настолько отлично, насколько
>отлично на SMP скалируется TCP/IP-стек вообще. С этим, правда, проблемы почти
>везде. :( Но во FreeBSD уже давно есть netisr, где всё
>хорошо. Пока речь не идёт о fragmentation/reassembly. :)
Ой. Шо, таки уже убрали один глобальный лок на весь PF ? Пока что на тестах файрволовна6-ке ipfw опережал в скорости pf, в среднем раза в полтора.
| |
|
|
5.21, Sampan (?), 21:43, 26/12/2007 [^] [^^] [^^^] [ответить] | +/– | Прочитал сие и сразу средце екнуло неужели к нам сам Rusty Russell заглянул, ли... большой текст свёрнут, показать | |
|
|
7.25, Дохтур (?), 22:11, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Аналог scrub и modulate state у iptables в
>студию.
Скажите, а часто вы на интенсивном трафике пользуетесь scrub & state modulation?
Да и пересборка пакетов - вещь затратная как по памяти, так и по cpu.
А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет pf.
Как и не умеет от SCTP, который во всю уже используется вменяемыми людьми.
И ECN не умеет, и по длине пакета матчить не может...
А вы говорите о каких-то полухакерских плюшках(passive os fingerprint из той же оперы).
> Я знаю "Ринет" с 1996 года, на магистрали
>там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости
>тона, проблемы, как всегда, на стороне клиента.
7206 - откровенное г-но.
| |
|
|
9.49, Аноним (-), 10:42, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | вы же прекрасно понимаете что прямых аналогов нет часть функционала есть в штат... большой текст свёрнут, показать | |
|
|
11.76, Аноним (-), 20:50, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | Ооох заглянем в в man http www freebsd org cgi man cgi query pf conf aprop... большой текст свёрнут, показать | |
|
|
13.83, Аноним (-), 21:15, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | снорт даст куда большую нагрузку на cpu Хотя бы потому что ему придётся слушать... большой текст свёрнут, показать | |
|
14.85, BB (??), 22:08, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать все в ло... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
9.98, Nick (??), 08:55, 28/12/2007 [^] [^^] [^^^] [ответить] | +/– | Вобщем-то, правильно сказали выше Некорректно требовать именно аналога вот это... текст свёрнут, показать | |
|
|
7.72, SunTech (?), 18:54, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Я знаю "Ринет" с 1996 года, на магистрали
>там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости
>тона, проблемы, как всегда, на стороне клиента.
Тоже знаю Ринет и знаю, подтверждаю, что там циски, но фрю там любят. Не рекламы ради, но мне нравился Ринет, к сожалению я переехал, и теперь скучаю по нему.
| |
|
6.86, Redacid (??), 22:13, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в
>умелых руках, конечно). Всякие кивки про лучшую производительность BSD на 4
>гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных
>каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие
>на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет.
>Как же их колбасит при суммарном транзитном трафике 500 - 800
>Гб в месяц! Я недавно от этого кошмара отключился - не
>нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало
>:-))
что вы плетёте??? какие 800 Гб - это 25 Гб в день
поверьте БСД способна перелопатить гораздо больше
Вы не думали, что просто их каналы были не такие уж широкие
| |
|
7.96, Andrew Kolchoogin (?), 01:58, 28/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> поверьте БСД способна перелопатить гораздо больше
> Вы не думали, что просто их каналы были не такие уж широкие
Издеваетесь, коллега?-)))
Там только на инфраструктуру MSK-IX гигабит. :)
| |
|
8.97, Redacid (??), 08:03, 28/12/2007 [^] [^^] [^^^] [ответить] | +/– | Вообще-то я имел ввиду ширину внешних каналлов, но не в этом суть Это всего лиш... большой текст свёрнут, показать | |
|
|
|
5.28, guest (??), 23:43, 26/12/2007 [^] [^^] [^^^] [ответить] | +/– | Это потрясающе - мало того, что сам нифига не знает, дык ещё и других поучать бе... большой текст свёрнут, показать | |
|
6.29, klez (??), 23:59, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот опять. Только дин думающий и вменяемый человек на опеннете высказался, как пришло двое, с личными комплексами и начали его грязью поливать, параллельно навешивая ярлыки и на своих провайдеров и на имя и фамилию человека, не побоявшегося подписаться.
| |
|
7.46, Andrew Kolchoogin (?), 09:25, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> на имя и фамилию человека, не побоявшегося подписаться.
Ну, я человек без комплексов, ФСБ не боюсь, так что подписываюсь везде и всегда реальным именем. :) И очень удивлён, что на OpenNet'е это необщепринятая практика. У участников форума схизис (расщепление личности) -- в RL одно, в Интернете -- другое?-)
| |
|
|
7.38, Аноним (38), 02:15, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | При админе-эникейщике все пофиг - все равно работать не будет Странно, а у меня... большой текст свёрнут, показать | |
7.39, V.O. (?), 04:52, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку
>на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь
>сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
>
имеется ввиду, что он у вас core router?
ЗЫ постинги на редкость осмысленные для опеннет, спсб
| |
7.53, гость (?), 12:12, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | Так, теперь ещё и ядро с дистрибутивом путаем вообще красота Ядро и базовые ... большой текст свёрнут, показать | |
|
|
9.74, Аноним (-), 20:04, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | да Андрей, вы же вроде адекватный человек А давайте туда постгрес с 50гигово... большой текст свёрнут, показать | |
|
10.75, BB (??), 20:46, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | Это как сказать, где-то умеет, с использованием мегахаков , а где то нет Есть ... большой текст свёрнут, показать | |
|
11.81, Аноним (-), 21:06, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | насчёт беты вы где прочитали зачем домашнему роутеру принимать fullview ospf ... большой текст свёрнут, показать | |
|
12.84, BB (??), 22:01, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | В рассылках, до сих пор существует проблемы которые не позволяют использовать ca... большой текст свёрнут, показать | |
|
13.88, Дохтур (?), 23:52, 27/12/2007 [^] [^^] [^^^] [ответить] | +/– | а мы с вами об одном и том же говорим я про http tservice net ru s0mbre old ... большой текст свёрнут, показать | |
|
14.101, BB (??), 10:33, 28/12/2007 [^] [^^] [^^^] [ответить] | +/– | Да именно, не так пока еще хорошо вылизано как в исходной ОС, второе не понятна ... большой текст свёрнут, показать | |
|
|
16.106, BB (??), 13:28, 28/12/2007 [^] [^^] [^^^] [ответить] | +/– | Ну вот об этом и речь, так как сам по себе голый carp не очень-то и нужен, как я... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|
5.40, V.O. (?), 05:04, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150 бит на пакет траффика (ну вы поняли) -- интересно ваше мнение
| |
|
6.44, Andrew Kolchoogin (?), 09:22, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или
> BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150
> бит на пакет траффика (ну вы поняли) -- интересно ваше мнение
Сложный вопрос. Как маршрутизатор, или как платформа для какого-то сервиса?
| |
|
7.56, V.O. (?), 15:08, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
как генератор помех на канале для тестирования в ims (те умный бридж)
ЗЫ байт на пакет...
| |
|
|
5.55, Алексей (??), 14:37, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>Слишком много точек входа в ядро, код перегружен и глючит.
>Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато
выдержки из man iptables
mac
--mac-source [!] address
Match source MAC address. It must be of the form
XX:XX:XX:XX:XX:XX. Note that this only makes sense for packets
coming from an Ethernet device and entering the PREROUTING, FOR-
WARD or INPUT chains.
>у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на
>лету, и поиск по которым осуществляется по RADIX Tree, а не
>по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих
>правила пакетного фильтра, _никогда_ не подерутся.
Так же неверная информация.
Не стоит забывать, что дропать покеты с бОльшей производительностью можно с помощью iproute
>Но пакетный фильтр -- это не то, за что идёт борьба на
>роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>использованием либо ASIC'ов, либо NPU. Period.
Т е вы утверждаете что пакетный фильтр слабо влияет на "пакетную производительность"? Это мягко говоря неверно 8-).
| |
|
6.67, Andrew Kolchoogin (?), 18:08, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> выдержки из man iptables
Вы невнимательно читаете мои комментарии.
Именно это я и написал. Что PF _не_ знает ничего про L2, а NetFilter знает.
В любом случае, спасибо за документальное подтверждение моих слов. ;)
> Так же неверная информация.
В смысле? У PF нет таблиц?-) pf.conf(5) Вас в этом легко разубедит. ;)
> Не стоит забывать, что дропать покеты с бОльшей производительностью можно с помощью
> iproute
Зачем их дропать? Задача маршрутизатора -- их не дропать. ;)
>> Но пакетный фильтр -- это не то, за что идёт борьба на
>> роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>> использованием либо ASIC'ов, либо NPU. Period.
> Т е вы утверждаете что пакетный фильтр слабо влияет на "пакетную производительность"?
> Это мягко говоря неверно 8-).
Как ни странно, слабо.
При правильной его настройке, конечно. Если использовать таблицы вместо линейного списка правил, использовать state filtering и ещё несколько техник, то слабо.
Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
А теперь, внимание, вопрос: а зачем так делать?-)
| |
|
7.82, Аноним (-), 21:09, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным
>списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
> А теперь, внимание, вопрос: а зачем так делать?-)
сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
На ipfw есть хоть динамические правила, а в pf?
| |
|
|
5.110, Кирилл (??), 10:53, 29/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>Слишком много точек входа в ядро, код перегружен и глючит.
>Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато
>у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на
>лету, и поиск по которым осуществляется по RADIX Tree, а не
>по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих
>правила пакетного фильтра, _никогда_ не подерутся.
>Но пакетный фильтр -- это не то, за что идёт борьба на
>роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>использованием либо ASIC'ов, либо NPU. Period.
Знает PF об ethernet. Есть там возможность фильтровать по мас-адресам на основе политик. Возможно немного вас не допонял. Я о том?
| |
|
|
|
|
|
2.23, Andrew Kolchoogin (?), 21:51, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>пакетный фильтр в случае ДоС как раз и спасает,
>особенно pf с лимитами
Особенно, когда DoS'ят Апач, вызывая динамический контент. Загрузка проца взлетает до 50-60, а лимиты всё ещё не исчерпаны. Ибо NAT'ы везде, и "задвигать" их сильно вниз некошерно.
| |
|
3.26, Дохтур (?), 22:17, 26/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Особенно, когда DoS'ят Апач, вызывая динамический контент.
у нормальных людей опач работает бэкэндом. А такую паразитную активность весьма просто пресечь, ограничив число входящих SYN в ед. времени экспоненциально.
Чуть более сложные меры вообще исключат подобный сценарий, оставив только возможность полностью забить канал входящим трафиком(но от этого никто не застрахован).
| |
|
4.34, Andrew Kolchoogin (?), 01:37, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Особенно, когда DoS'ят Апач, вызывая динамический контент.
> у нормальных людей опач работает бэкэндом.
И что? Он от этого как-то сильно меньше CPU Time кушать начинает?
> А такую паразитную активность весьма просто пресечь, ограничив число входящих SYN
> в ед. времени экспоненциально.
Exponential Backoff в данном случае совершенно бесполезен, так как это лишь _одна из возможных реакций_ на активность с некоторого IP-адреса. Тупой сброс соединений -- это, если хотите, EB после предельного перехода. :)
Ну и что? Всё равно микропроцессор на Apache просядет. Как не выкручивайся. Потому, что не за'backoff'ить каждый конкретный IP без риска за'backoff'ить огромную сеть за NAT'ом.
А вот разговоры в ключе "ну и сами виноваты, пусть меняют провайдера" я считаю тупиковыми.
> Чуть более сложные меры вообще исключат подобный сценарий, оставив только
> возможность полностью забить канал входящим трафиком(но от этого никто не застрахован).
Почему, можно попытаться прогнуть апстрима на RSVP. :)))
| |
|
5.51, Аноним (-), 10:56, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> И что? Он от этого как-то сильно меньше
>CPU Time кушать начинает?
Да с cpu time не проблема. Опач обычно в prefork гоняют, так что чаще упираешься в пямять.
Да и кеширование на фронтенде решает ;))
> Ну и что? Всё равно микропроцессор на Apache
>просядет. Как не выкручивайся. Потому, что не за'backoff'ить каждый конкретный IP
>без риска за'backoff'ить огромную сеть за NAT'ом.
Имхо, слабый DoS должен никак не сказываться на работе сервиса. А что-то более заметное будет иметь вполне очевидный профиль. И, кстати, борьба с DoS - это всегда компромисс и риск false positives.
> А вот разговоры в ключе "ну и сами
>виноваты, пусть меняют провайдера" я считаю тупиковыми.
+1
PS: спасибо за адекватную и достаточно сдержанную дискуссию.
| |
|
6.68, Andrew Kolchoogin (?), 18:13, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> И что? Он от этого как-то сильно меньше CPU Time кушать начинает?
> Да с cpu time не проблема. Опач обычно в prefork гоняют, так
> что чаще упираешься в пямять.
Согласен.
> Да и кеширование на фронтенде решает ;))
Далеко не всегда.
В большинстве случаев, с которыми мне приходилось встречаться, Web-код написан, прямо скажем, не очень хорошо. Не сказать жёстче: руки бы повырывать. ;) И "агрессивное" кэширование приводит к появлению stale pages. А "кооперативное" кэширование на фронтэнде при помощи какого-нибудь memcached ещё в Web-код встраивать надо, а в плохой код его встроить просто невозможно.
> Имхо, слабый DoS должен никак не сказываться на работе сервиса. А что-то
> более заметное будет иметь вполне очевидный профиль. И, кстати, борьба с
> DoS - это всегда компромисс и риск false positives.
Равно, как и борьба со спамом. Подписываюсь под каждым словом.
| |
|
|
4.41, Nikolay (??), 05:29, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Пакетный фильтр вас не спасет при DOS-е службы. Уж слишком низкий может оказаться порог для дос аткаки. Обычный index.php какого-нибудь треклятого форумного движка может быть целеноправленно атакован сравнительно небольшим количеством запросом и ваш фильтр даже не сможет выделить эти аномалии из фона, а апач будет буксовать глотая последние мегабайты свопа.
| |
|
5.45, Andrew Kolchoogin (?), 09:23, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Обычный index.php какого-нибудь треклятого форумного движка
index.php ещё, как правило, переживаемо. А вот index.pl может уже на 50 запросах/сек ТА-А-А-АК раскорячить Apache... :)
| |
|
6.47, Аноним (38), 10:17, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
ОФФ: Andrew Kolchoogin, респект за грамотную дискуссию. Кое-что "открыл" для себя, что следовало бы знать уже лет 8 как, чьорт побьери. Век живи - век учись! :-)
Побольше бы таких участников конференций. Может, и с квалификацией кадров получше стало бы? :-)
PS Просьба не обращать внимания на профессиональных флеймогонов - это единственное, что они знают толком.
| |
|
7.54, гость (?), 12:16, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>ОФФ: Andrew Kolchoogin, респект за грамотную дискуссию. Кое-что "открыл" для себя, что
>следовало бы знать уже лет 8 как, чьорт побьери. Век живи
>- век учись! :-)
>Побольше бы таких участников конференций. Может, и с квалификацией кадров получше стало
>бы? :-)
>PS Просьба не обращать внимания на профессиональных флеймогонов - это единственное, что
>они знают толком.
Андрюша, хватит уже отвешивать себе комплименты с помощью виртуалов - смотреть противно!
Так и до дурки не далеко...
| |
|
6.52, Antrew (??), 11:21, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> Обычный index.php какого-нибудь треклятого форумного движка
>
> index.php ещё, как правило, переживаемо. А вот index.pl
>может уже на 50 запросах/сек ТА-А-А-АК раскорячить Apache... :)
Не надо наезжать на Perl, ибо связка mod_perl + Apache дает очень хорошую производительность.
| |
|
7.71, Andrew Kolchoogin (?), 18:29, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Не надо наезжать на Perl, ибо связка mod_perl + Apache дает очень
> хорошую производительность.
Упаси меня Ларри наезжать на Perl. Просто PHP-интерпретатор легче перлового.
| |
|
6.99, Nick (??), 09:36, 28/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
впику Вашей нелюбви к Netfilter
проблема: DoS на вебсервис и границы синов далеки до реакции, а апач, как выше выразилиьсь, доедает своп...
Что делать BSD админу - неизвестно.
А вот в Линухе проблема имеет вид даже некоторого решения.
Пишеться модуль, который в зависимости от нагрузки на CPU и/или винта и/или память, принимает или дропает пакет, собирается для текущего ядра и загружается в него.
Аналогичный модуль-собрат пишется и для user-level iptables тулзы.
Все границы/лимиты задаются параметрами этого user-level модуля из команды iptables.
Зависимость на род нагрузки исчезает. Это может быть сколь угодно плохой и неоптимальный пользовательский код.
В результате: можно вести разговор о дропе новых соединений, если загрузка системы и/или этих 3-х подсистем выше заданной. А также, совмещать эти лимиты с другими сетевыми ограничениями.
На практике получается более чем красивое и элегантное решение.
Например: в зависимости от нагрузки (уровни нагрузки: 5-10, 10-20, 20-30...) регулируется количество одновременных коннектов из /24 сетки (например: 50, 30, 10...). И даже глубина битности измеряемых сетей: /24, /25, /26....
В результате имеем более равномерное распределение мощностей системы между клиентами в условиях DoS'a.
Чем бы порадовал PF?
| |
|
7.102, pavel_simple (ok), 10:37, 28/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
могу ошибаться -- но как мне думается тут и писать ничего не придётся
проблему можно будет решить например так
несколько recent (в зависимости от нагрузки) соответственным образом помечают пакет (-j MARK)
а потом в зависимости от марки используем limit
| |
7.109, Аноним (-), 21:42, 28/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
дописать модуль к тому же apache, чтоб он рулил этой политикой, тогда можно хоть электрическим реле провода размыкать. это ниразу не дело ядра.
| |
7.118, nuclight (?), 22:42, 30/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ой, и вы ЭТО называете красивым и элегантным решением?! Это же жуткий костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно на одной машине). Если уж у вас такие DoS'ы, с которыми справляется ядро.
Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это криво. Такие вещи следует в юзерлэнде же и отрабатывать, выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и анализатор (на сервере же только датчики). В ядре отслеживать, что конкретно не нравится процессу - слишком сложно.
Наконец, когда решением предлагается _написать_ модуль ядра (!) - тут уже лицемерно говорить, что в одной ОСи это можно сделать, в другой нет - специалист, на такое способный, сделает для любой, средства есть.
Другое дело, что это может быть невозможно даже при наличии специалиста - например, когда ДДОСили bash.org.ru, они не имели возможность поменять на машине netfilter на nf-hipac - тупо из-за VDS (решили доморощенным аналогом). Да, хостер был плохой (потом сменили), да, отслеживание и перекрытие DoS'ов вообще задача хостера, ну вот такие были условия, что поделать...
Отсюда, кстати, видно, что предложенный к написанию модуль тем более хуже - сыграет на руку DDoS'у, дропая, возможно, вполне легитимные коннекты - не те критерии ибо.
| |
|
8.120, Nick (??), 23:57, 30/12/2007 [^] [^^] [^^^] [ответить] | +/– | Угу кому следует орагнизовывать схему - тот организовывает схему А кому следует... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
2.59, Аноним (-), 17:36, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Извините за оффтоп, но ві такими выпадами похожи на журналиста желтой прессы, который вместо веских аргументов кричит "Ба, да он же пидар (наркоман, алкоголик, нужное подчеркнуть)".))))
| |
|
3.64, Andrew Kolchoogin (?), 18:01, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Извините за оффтоп, но ві такими выпадами похожи на журналиста желтой прессы,
> который вместо веских аргументов кричит "Ба, да он же пидар (наркоман,
> алкоголик, нужное подчеркнуть)".))))
Да хоть всё сразу. :) Мне приятно ощущать свою уникальность в антиобщественности.
Только вот какая незадача: гугл индексирует и этот сайт, и этот форум. И когда-нибудь кто-нибудь попытается поискать опусы этих граждан, и что он найдёт?-)
Не рой другому яму -- пусть сам роет. ;)
| |
3.78, KdF (??), 21:02, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Может быть я и есть журналист желтой прессы, откуда вам знать?
А завтра напишу статью "Сисадмины-наркоманы идут на город" или "Величие и позор русской школы системного администрирования".
Что касается непосредственно темы, то я это просто ради интереса посмотрел, чтобы понимать, с кем имею дело, когда хотел вступить в дискуссию по вопросу.
Учитывая безапелляционный тон и однобокую аргументацию данного участника дискуссии желание вступать в нее пропало, да тем и лучше, ибо в споре, как известно, никакой истины нет, а есть только ересь и отстаивание собственных заведомо верных точек зрения.
Ну а запостил я так, шутки ради, очень уж смешным мне это показалось.
| |
|
2.63, Andrew Kolchoogin (?), 18:00, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Видим ниже
> Andrew Kolchoogin 2:5020/118.22 Thu 06 Apr 95 19:54
>
> Это давно, всерьез и похоже навсегда.
Кроме IT, в мире есть ещё много увлекательных наук. Химия, например. Или математика. А с компактными (то есть, с замкнутыми и ограниченными) людьми на OpenNet'е мне встречаться
крайне странно. ;)
| |
|
1.58, Mikhail (??), 17:01, 27/12/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
KdF, спасибо посмеялся. Гугл очень силен =)
Хочется вериться, что Andrew Kolchoogin все таки находиться в трезвом уме по понедельникам.
Andrew Kolchoogin, спасибо за комментарии.
| |
|
2.65, Andrew Kolchoogin (?), 18:03, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> KdF, спасибо посмеялся. Гугл очень силен =)
Да, Гугль про меня много разного рассказывает. :)
> Хочется вериться, что Andrew Kolchoogin все таки находиться в трезвом уме по
> понедельникам.
Абсолютно. Химия и физиология психотомиметиков перестала меня интересовать примерно лет восемь назад.
| |
|
3.79, sash (??), 21:03, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Замечательная дискуссия.
Андрей - вопрос, если можно:
"Где учат" кошерной работе с пакетными фильтрами? На самом деле интересует "идеология".
Ответ может выглядеть так: средства отладки такие-то, best-practice вот такая-то и т.д.
Почитав Ваши посты про ускорение работы ПФ узнал несколько новых подходов в написанию правил, очень забавно. :) Система может получиться очень красивой.
| |
|
4.93, Andrew Kolchoogin (?), 01:51, 28/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Андрей - вопрос, если можно:
>
> "Где учат" кошерной работе с пакетными фильтрами? На самом деле интересует "идеология".
Да вот, здесь, на OpenNet'е. Если, конечно, отфильтровывать гон от дискуссий.
> Ответ может выглядеть так: средства отладки такие-то, best-practice вот такая-то и т.д.
Если бы всё было так просто... ;)
| |
|
3.80, sash (??), 21:05, 27/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
И еще вопрос:
Вы действительно где-то используете RSVP?
| |
|
|
|
2.100, Nick (??), 09:39, 28/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>мда, виртуальные интерфейсы по прежнему не поддерживаются.
пардон
поясните что именно не поддерживается?
| |
|
3.121, я (?), 13:09, 09/01/2008 [^] [^^] [^^^] [ответить]
| +/– |
видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ...
| |
|
4.122, Nick (??), 15:54, 09/01/2008 [^] [^^] [^^^] [ответить]
| +/– |
>видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ...
а...
ну так это ж не отдельный интерфейс, и даже не виртуальный :)
это просто label для алиаса, не более.
За сим -i eth1 == -i eth1:500
| |
|
|
|
|