>>Лимит количества подключений в единицу времени логично как раз централизовано на
>>фаерволе делать, а не в каждой проге логику прикручивать, не?
>
>Вообще-то мое глубокое убеждение что хорошему демону костыли со стороны фаерволла просто
>не требуются. То есть, если на него ломится 100500 потоков -
>он должен или их обслужить без проблем или как-то затроттлить нагрузку
>на систему до вменяемой величины/послать на йух тех кто абузивно использует ресурс и т.п.Молодой человек, а Вы в курсе, какую цену имеет порождение процесса, а какую - обработка пакета файрволом? Вы пробовали проверять Ваши убеждения на соответствие реальности?
>При том файрвол не знает в отличие от
>демона какое использование ресурсов демона приемлимо, а какое - нет. И
>обучать фаер защищать задницу каждого демона - довольно геморно, вообще-то, и
Зато системный администратор знает, ибо именно это и является его работой.
>попахивает костылестроением. Посему я резонно полагаю что демон который этого требует
>- не очень качественный, и это как бы некоторая проблема секурити,
>что демону вообще нужны услуги защитника-файрвола чтобы он не жрал ресурсы. [...]
>Ну вот о надежности я уже сказал - когда жрется 30% проца
>и висит пачка левых процессов только потому что хацкер Вася видите
>ли вышел побрутфорсить - насчет надежности возникают некоторые предъявы.
Молодой человек, Вы в курсе, чем отличаются понятия "надежность" (reliability), "безопасность" (security) и "производительность" (performance)? Вы в курсе, что они зачастую выдвигают противоречивые требования?
>Исключения по жрачу ресурсов допустимы только в случае когда система чисто ради
>этого конкретно демона и поставлена в основном (например, на сервере баз
>данных процессам БД допустимо выюзать ресурсы машины, etc). И то -
>такие демоны чаще всего недоступны снаружи, ибо нефиг и проблем с
>нагрузкой извне - нет.
DDoS-атака на веб-сервер запросами "GET /" - вполне легитимные юзеры запрашивают это же. В файрволе юзеры с такии запросами при превышении количества фильтруются с небольшой затратой ресурсов, сервер продолжает работать. Анализ в демоне потребует куда больших затрат в ресурсах. Тому, кто предложит увеличить нагрузку на сервер в условиях атаки, стоит подумать об увольнении.
>openssh без проблем жрет 30% атлона 3000+ и форкает процессы "только
>потому что какой-то козел решил сегодня побрутфорсить". Козел,
>конечно, своей цели не достигает,
Следовательно, свойство "безопасность" (security) не нарушено, демон свою задачу выполнил. Обеспечение свойства "производительность" выполняется другими путями, см. учебники.
>>>в ШЕЛЛ пхать по дефолту всякие портфорварды, впны, сфтп и прочая?
>>Затем, что это удобно и очень облегчает жизнь.
>>Каждый день пользуюсь этими фичами.
>
>А я пользуюсь ими раз в сто лет (ну, еще sftp -
>изредка и не везде, мля).
Это показывает только то, что Ваши задачи - недалеки от песочницы. У меня на работе обеспечение шифрованной (безопасной) передачи файлов (scp, иногда для пользователей sftp) и проброса TCP-соединений является _необходимым_ - эта функциональность используется каждый день.
>>См. выше. У каждой программы есть своя сфера ответственности. И в своей
>>сфере OpenSSH на данный момент безусловный лидер.
>
>Вот только оно зачем-то лезет еще в 100500 сфер, которые по логике
>вещей вообще не сфера ответственности секурного шелла + собственно с секурти
>себя любимого не очень хорошо справляется, раз уж требует защиты своей
>жопы фаером.
Молодой человек, еще раз перечитайте учебники на предмет определений, что такое security и что такое performance.
>>Примеры более фичастых и удобных
>
>А от секурного шелла не требуется быть адски фичастым. От него требуется
>быть нормальным СЕКУРНЫМ ШЕЛЛОМ. А не каким-то там качальщиков файлов, портфорвардером
>и недовпном, строго говоря. Если мне надо будет впн или портфорвардер
>- их отдельных на разные вкусы и задачи есть.
Молодой человыек, меня берут сомнения, что Вы в состоянии представить более удобные утилиты для портфорвардинга, нежели применение ключей -L, -R, -D в ssh. Которые, заметим, кроме собственно форвардинга обеспечивают _безопасную_ (secure) передачу данных. Назовите хотя бы парочку.
