LINUX.ORG.RU

Угроза безопасности, создаваемая отслеживанием связанных соединений на фаерволе

 , , ,


0

0

На днях в рассылке разработчиков netfilter/iptables появилось сообщение, рассказывающее об угрозах, создаваемых корректной обработкой активного режима FTP на примере Linux-фаервола netfilter (nf_conntrack_ftp и nf_nat_ftp).

Активный режим FTP работает следующим образом: сначала FTP-клиент инициирует TCP-соединение на FTP-сервер (обычно на порт 21) и регистрируется на нем (выполняет команды USER и PASS). При возникновении необходимости передать какие-либо данные, не являющиеся командами, клиент открывает один из своих портов на прослушивание и передает номер этого порта серверу в команде PORT, после чего сервер открывает на этот порт второе соединение (соединение данных, в отличие от первого — управляющего) и передает необходимые данные (например, файл или листинг каталога).

Так как номер клиентского порта для прослушивания обычно выбирается случайно, корректная обработка таких сеансов межсетевыми экранами и NAT представляет определенные трудности, которые разработчики фаерволов пытаются решить.

Например, в фаерволе netfilter, встроенном в ядро Linux, данная проблема решается путем использования специальных модулей ядра (так называемых conntrack helpers и NAT helpers), которые сканируют трафик, по специальным шаблонам выделяют передаваемые номера портов и обеспечивают их своевременное открытие, а также корректный проброс соединений через NAT.

В системе OpenBSD эта задача решается во многом аналогичным образом, однако вместо модулей ядра используется userspace-демон ftp-proxy, который добавляет соответствующие правила к нужным якорям (anchors) фаервола pf.

Важно отметить, что в любом случае корректная обработка активного режима FTP-связана с открытием на доступ извне порта на клиентском хосте.

Угроза, создаваемая подобными техническими средствами, обусловлена невозможностью отличить, инициируется ли соединение обычным FTP-клиентом на обычный FTP-сервер, или такое поведение имитируется злонамеренным ПО (malware). Например, используя технологии XMLHTTPRequest, Adobe Flash или Java-апплеты, злоумышленник может подготовить специальную web-страницу, при открытии которой на клиентском хосте может быть использована данная узвимость. Злонамеренный код, исполняемый на клиентском хосте, имитирует работу обычного FTP-клиента в активном режиме, отправляя на сервер злоумышленника команду PORT. В том случае, если межсетевой экран настроен на корректную обработку активного режима FTP, это приведет к открытию заданного клиенского порта для доступа с сервера злоумышленника.

Автор сообщения приводит также ссылку на git-репозитарий с комплектом ПО, разработанного специально для демонстрации этой уязвимости (проще говоря, эксплойтом).

Заметим, что к данной угрозе чувствительны не только персональные (работающие на клиентском хосте) фаерволы, но и традиционные межсетевые экраны, работающие на шлюзах и NAT. В последнем случае фаервол не только разрешит доступ к порту клиента в локальной сети, но и обеспечит проброс на этот порт соединения извне.

Ну и наконец, стоит заметить, что причины возникновения обсуждаемой проблемы лежат не в каких-либо ошибках при разработке фаерволов, а в изначальной некорректности (defective by design) принципов работы некоторых протоколов прикладного уровня, в частности, активного режима FTP.

>>> Подробности

★★★★

Проверено: boombick ()

Вообще, получается, любое активное соединение является источником угрозы, потому что оно предусматривает «проброс порта».
Ну и чем, принципиально, будет отличаться некая malware софтина, работающая в active и passive режиме?

CyberTribe ★★ ()
Ответ на: комментарий от CyberTribe

>любое активное соединение является источником угрозы

Ну и чем, принципиально, будет отличаться некая malware софтина, работающая в active и passive режиме?


Что вы понимаете под термином «активное соединение»?

nnz ★★★★ ()
Ответ на: комментарий от CyberTribe

Нда, термин немного необычный... ну да ладно.

Тогда утверждение

Вообще, получается, любое активное соединение является источником угрозы

по сути своей верно.

Только замечу, что есть дополнительное условие — атакуемый фаервол должен поддерживать данную конкретную разновидность «активных соединений».

nnz ★★★★ ()
Ответ на: комментарий от nnz

Я это к тому, что собственно проблема безопасности не в том, как работает фаерволл, а в самом принципе работы таких «активных соединений» (как их правильно называть?
Соотвественно заголовок скорее звучать должен «Архитектурная уязвимость „Активного режима“ протокола ftp», ибо уязвимость там, а не в работе фаерволла. Верно?

CyberTribe ★★ ()

Когда ktorrent научится использовать это для проброса портов?)

farafonoff ★★ ()

Когда же FTP станет историей, пароль открытым текстом, вот эта ошибка дизайна активного режима, низкая производительность, только для домашних нанолокалок (одна квартира) пригоден. А разрабам ipfilter ломать голову теперь надо.

Всякий скайп небось таким макаром и лезет через фильтры.

anonymous ()

А кто-то еще пользуется активным ftp ? Да еще такую дыру в межсетевой экран вставляет???

wWolf ()
Ответ на: комментарий от anonymous

> Когда же FTP станет историей, пароль открытым текстом, вот эта ошибка дизайна активного режима, низкая производительность, только для домашних нанолокалок (одна квартира) пригоден. А разрабам ipfilter ломать голову теперь надо.

Даже для квартиры SFTP как-то сподручнее — речь не о том, что шифрованное, а о том, что детских болезней FTP нет. Ну и еще HTTP + надстройки над ним.

shimon ★★★★★ ()

Как бы это сказать... проблемы нету. Просто факт - ответственность за безопасность перекладывается с фаервола на непосредственно FTP клиент (если он не дыряв то волноваться не очём).

stalkerg ★★★★★ ()

Прошу прощения, я немного не в теме. Зачем вообще сегодня нужен активный FTP? Чем он лучше пассивного FTP? В чем его преимущества?

Harliff ★★★★★ ()
Ответ на: комментарий от stalkerg

В данном слчае никакой ответственности ни фаер ни ftp-клиент (коего на атакуемой машине и вовсе может не быть) не несут, а виноват именно _протокол_, т.е. вообще наличие активного режима ftp и что его еще кто-то использует, а значит механизм его может задействовать и злобный троян.

wWolf ()

Бред собачий

Ну и наконец, стоит заметить, что причины возникновения обсуждаемой проблемы лежат не в каких-либо ошибках при разработке фаерволов, а в изначальной некорректности (defective by design) принципов работы некоторых протоколов прикладного уровня, в частности, активного режима FTP.

Тот кто это написал наверное в жизни в глаза не видел RFC959. С помощью комбинации активных/пассивных соединений можно строить целые системы которым надо менятся инфой или кластера.

В данной уязвимости виноват исключительно файрволл - нехер было не разобравшись по сути нахрена так было сделано в FTP писать костыли для проброса активных соединений из-за ната.

r ★★★★★ ()
Ответ на: комментарий от CyberTribe

Верно?

Неверно. Тут виноват агент совершающий проброс. Если таким агентом будет не модуль ядра, а скажем сисадмин пишущий правило в файрволе на незащищенный внутренний ресурс - тоже внутренний ресурс виноват?

r ★★★★★ ()
Ответ на: комментарий от anonymous

Всякий скайп небось таким макаром и лезет через фильтры.

Всякий скайп походу юзает клиентов с реальным айпишником в качестве релеев.

r ★★★★★ ()
Ответ на: комментарий от Harliff

>Зачем вообще сегодня нужен активный FTP?
Он меньше тормозит.

Ramen ★★★★ ()
Ответ на: комментарий от CyberTribe

>Я это к тому, что собственно проблема безопасности не в том, как работает фаерволл, а в самом принципе работы таких «активных соединений» (как их правильно называть?

Ну я в общем так и написал

Ну и наконец, стоит заметить, что причины возникновения обсуждаемой проблемы лежат не в каких-либо ошибках при разработке фаерволов, а в изначальной некорректности (defective by design) принципов работы некоторых протоколов прикладного уровня, в частности, активного режима FTP.


Что касается терминологии, то лично я и мои коллеги по работе используем термин «связанные соединения».

nnz ★★★★ ()
Ответ на: Бред собачий от r

>Тот кто это написал наверное в жизни в глаза не видел RFC959. С помощью комбинации активных/пассивных соединений можно строить целые системы которым надо менятся инфой или кластера.

Широкие возможности, открываемые «особенностями» протоколов, вовсе не отменяют дефективный характер этих особенностей.

В данной уязвимости виноват исключительно файрволл - нехер было не разобравшись по сути нахрена так было сделано в FTP писать костыли для проброса активных соединений из-за ната.


Принципиально важный момент — именно _корректная_ обработка «особенностей» протокола приводит к уязвимости.

Термин «костыль» здесь не имеет никакого смысла, ибо какова задача, таково и решение.

Впрочем, вижу у вас нездоровый красноглазый фанатизм. Уже начинает доставлять :)

nnz ★★★★ ()
Ответ на: комментарий от r

>Неверно. Тут виноват агент совершающий проброс.

Чистейшей воды демагогия.

Проброс _необходим_ для корректной работы протокола.
А значит, виноват именно протокол.

nnz ★★★★ ()
Ответ на: комментарий от stalkerg

>проблемы нету. Просто факт - ответственность за безопасность перекладывается с фаервола на непосредственно FTP клиент

Да вот нифига. Злобный сервер просит клиента открыть конкретный порт. На этом порту у клиента уже слушает какое-либо уязвимое приложение и совсем не FTP-клиент.

ModeZt ()
Ответ на: комментарий от anonymous

>Когда же FTP станет историей, пароль открытым текстом, вот эта ошибка дизайна активного режима, низкая производительность, только для домашних нанолокалок (одна квартира) пригоден. А разрабам ipfilter ломать голову теперь надо.

Ходят слухи, что IRC тоже подобную хрень позволяет.

nnz ★★★★ ()
Ответ на: комментарий от nnz

Широкие возможности, открываемые «особенностями» протоколов, вовсе не отменяют дефективный характер этих особенностей.

Они не дефективные. Ты формат команды порт видел? Догадайся с трех раз нахрена там передавать адрес? Или покури пунткт 2.3 (картинка 2).

Принципиально важный момент — именно _корректная_ обработка «особенностей» протокола приводит к уязвимости.

Ничего подобного. Такой проброс в принципе не надо было делать.

Термин «костыль» здесь не имеет никакого смысла, ибо какова задача, таково и решение.

Задача решается пассивными соединениями. А это костыль.

Впрочем, вижу у вас нездоровый красноглазый фанатизм.

Мой фанатизм основан на изученных от корки до корки RFC связанных с FTP.

r ★★★★★ ()
Ответ на: комментарий от nnz

Проброс _необходим_ для корректной работы протокола.

Нет. Это костыль сделанный потому что кому-то пришло в голову подпереть файрвол так чтобы изза ната работало активное соединение. Вопрос тут в корне - нахрена это нужно чтобы оно работало из-за ната?

r ★★★★★ ()

а upnp, это сьло быть, дыра активного ftp, очищенная от кода самого ftp?

AVL2 ★★★★★ ()
Ответ на: комментарий от r

мне приходит в голову метафора, сначала на чали забивать гвозди микроскопом, а потом предьявлять претензии производителям микроскопов, что у них ударостойкость линз слабая.

Активное соединение судествует не для этого. Если есть претензии к безопасности проброса - не пробрасывай - что это вообще за бардак - может и веб-бровзеру открывать порты для какой нить херни и заниматься пробросом? А то нагородили костылей а потом претензии что «мы по гвоздю микроскопом стукнули - а линза треснула - хреновый у вас микроскоп».

r ★★★★★ ()
Ответ на: комментарий от r

>Они не дефективные. Ты формат команды порт видел? Догадайся с трех раз нахрена там передавать адрес? Или покури пунткт 2.3 (картинка 2).

Я Ъ, поэтому по ссылкам не ходил.

Но телепатия, основанная на огромном жизненном опыте, подсказывает мне, что вы пытаетесь оправдать дефективность FTP, воспевая возможности FXP. Ну так я и не отрицаю, что «говно-то орехами». Но от этого оно не перестает быть говном.

Кроме того, тот же FXP может быть использован для проведения (D)DoS-атак (в RFC об этом написано?), и поэтому он практически везде заблокирован. Превентивно.

Ничего подобного. Такой проброс в принципе не надо было делать.


Активный режим есть? Есть. Клиенты используют? Используют.
Значит, необходимо. Для корректной работы.

Задача решается пассивными соединениями. А это костыль.


Оба режима абсолютно полноправны. И большинство клиентов используют по умолчанию именно активный режим.

Вот когда последний такой клиент уйдет на свалку истории — можете снова начать рассуждать, что «активный-де режим вовсе не для этого».

nnz ★★★★ ()
Ответ на: комментарий от r

>Нет. Это костыль сделанный потому что кому-то пришло в голову подпереть файрвол так чтобы изза ната работало активное соединение.

Повторяю — какова задача, таково и решение.

Вы упорно пытаетесь обгадить единственно возможное решение задачи, старательно обходя вопрос корректности постановки этой задачи.

Активный режим является режимом по умолчанию для абсолютного большинства специализированных FTP-клиентов. И именно поэтому возникла необходимость в его корректной обработке на фаерволах.

nnz ★★★★ ()
Ответ на: комментарий от r

>Активное соединение судествует не для этого.

Лично мне (да, наверное, и большинству читателей этого треда) глубоко пофигу, для чего _по-вашему_ существует активный режим.

Принципиально важно, для чего он _используется_ в настоящее время. А используется он именно для простого обмена данными между одним клиентом и одним сервером. И играет в этом процессе ключевую роль.

Выпилить активный режим — означает выпилить FTP как класс.

nnz ★★★★ ()
Ответ на: комментарий от nnz

Кроме того, тот же FXP может быть использован для проведения (D)DoS-атак (в RFC об этом написано?), и поэтому он практически везде заблокирован. Превентивно.

Опять же - он и не создавался для публичных сеток.

Есть фичи протокола FTP котоыре могут пользоваться в публичных сетках. Есть фичи которые не могут - и сделаны для частных сеток. Если кто-то достает фичу для сачтных сеток, высовывает ее в публичную сетку - кто ему злобный буратина?

Значит, необходимо. Для корректной работы.

В icq и прочих скайпах есть direct connect. Есть торренты. Давай и для них подопрем файрволы, а потом будем плакать что IM протоколы позволяющие direct connect дефективные бай дизайн, фотому что кто угодно может засунуть майлвару которая фейкнет протокол любой подобной хрени и файрвол ошибется?

Оба режима абсолютно полноправны.

Как я уже говорил в протоколе FTP есть куча фичь что и не снилась юзерам. Клиенты всегда реализуют подмножество. Считать активный режим дефаултным или расчитывать что он будлет работать из-за ната - это проблемы буратин а не протокола.

r ★★★★★ ()
Ответ на: комментарий от nnz

Вы упорно пытаетесь обгадить единственно возможное решение задачи, старательно обходя вопрос корректности постановки этой задачи.

Ее не надо было решать!

Для скайпа уже начали решать такую задачу в ядре? А то у меня файлы медленно качаются.

r ★★★★★ ()
Ответ на: комментарий от nnz

для чего _по-вашему_ существует активный режим.

Не по моему а по мнению господ Постела и Рейнольдса. А то что пофигу людям матчастью не озабтившимся, пофигу тем кто ей озаботился.

Принципиально важно, для чего он _используется_ в настоящее время.

То есть ты таки настаиваешь что в том что микроскоп плохо забивает гвозди виноват производитель микроскопов?

А используется он именно для простого обмена данными между одним клиентом и одним сервером

С _реальными_ IP.

r ★★★★★ ()

На днях в рассылке разработчиков netfilter/iptables появилось..

Ах вот оно как. Что же они, совсем за современным миром не следят? Анестезиолог успешно провёл опыты с анабиозом? :)

Мне казалось, это документированная всем известная фича. Все правила всегда пишутся с учётом этих вещей.

Ну, ладно, за всех не скажу, но лично я о способах «залезания за NAT» информацию видел ещё году в 2004. Конкретно этот пример (с nf_nat_подставить_нужный_протокол и браузером) точно мелькал во phrack скольки-то летней давности на примере трекинга IRC-протокола.

sedogrep ()

я думаю это проблема софта, выполняющего чужой код — т.е. флеши, явы и возможно браузера

флешь например должна запрещать выполняющемуся под ней коду лезть на те порты, которые приводят к открытию локальных портов и пробросу соединения на них, ну или спрашивать юзера об этом

www_linux_org_ru ★★★★★ ()

К стати этого открывателя в рассылке уже послали на тему К.O.

That is what helpers are supposed to do. If that poses a security risk, to your network, I advise not to use them.

r ★★★★★ ()
Ответ на: комментарий от r

>Опять же - он и не создавался для публичных сеток.

Опять же — nobody cares для чего что-то делалось.
Важны лишь фактические последствия действия.

Есть фичи протокола FTP котоыре могут пользоваться в публичных сетках. Есть фичи которые не могут - и сделаны для частных сеток. Если кто-то достает фичу для сачтных сеток, высовывает ее в публичную сетку - кто ему злобный буратина?


Можно очень долго рассуждать, что что-то предназначено вовсе не для того, для чего оно используется сейчас. На объективной реальности это не отразится.

Как я уже сказал, клиенты хотят работать в активном режиме. Ну не устраивает их по скорости пассивный. А активный режим небезопасен. Следовательно, протокол — говно.

В icq и прочих скайпах есть direct connect. Есть торренты. Давай и для них подопрем файрволы, а потом будем плакать что IM протоколы позволяющие direct connect дефективные бай дизайн, фотому что кто угодно может засунуть майлвару которая фейкнет протокол любой подобной хрени и файрвол ошибется?


Да можно и ничего никуда не засовывая сказать, что такие режимы говно.

Как я уже говорил в протоколе FTP есть куча фичь что и не снилась юзерам.


Да пожалуйста, используйте этот FTP у себя в спальне темной ночью за запертой дверью. Это ваше частное дело, и возражать не имеет смысла.

Но для публичных сетей FTP, как сочетание тормозного пассивного режима и дырявого активного, совершенно неприемлем.

Считать активный режим дефаултным или расчитывать что он будлет работать из-за ната - это проблемы буратин а не протокола.


Начнем с простого вопроса: протокол предусматривает защиту от нецелевого использования активного режима? Нет? Значит, это его проблемы.

Или покажите мне хотя бы один официальный документ, в котором категорически запрещается использование активного режима в публичных сетях.

nnz ★★★★ ()
Ответ на: комментарий от r

>Не по моему а по мнению господ Постела и Рейнольдса. А то что пофигу людям матчастью не озабтившимся, пофигу тем кто ей озаботился.

Если бы они действительно так думали, то обязательно бы запретили использование активного режима в публичных сетях. Но во времена создания FTP всем было пофигу на безопасность.
А вот теперь нам приходится расхлебывать последствия.

С _реальными_ IP.


А работа с серыми айпишниками официально запрещена? Нет? Значит, и с серыми тоже.

nnz ★★★★ ()
Ответ на: комментарий от nnz

Важны лишь фактические последствия действия.

Фактические последствия действий лежат на плечах деятелей. Если деятели думают что микроскоп подходящее для забивания гвоздей действие - ССЗБ.

Как я уже сказал, клиенты хотят работать в активном режиме.

Перефразируя - клиенты ходят голой жопой в мокрую^W^W открытый интернет. Ну и кто в этом виноват?

А активный режим небезопасен.

Direct Connect в IM тоже не безопасен? С фактической стороны он ничем не отличается от активного режима FTP.

Да можно и ничего никуда не засовывая сказать, что такие режимы говно.

Ну конечно! Интернет придумали для хоумбоев с файлзилами в домашних сетках.

Но для публичных сетей FTP, как сочетание тормозного пассивного режима и дырявого активного, совершенно неприемлем.

В публичную сеть и не надо ходить активным режимом. Активный режим выставляет голую жопу в интернет и не важно стелано это пакетным фильтром или реальным айпишником. Если не знаешь что делаешь - не выставляй.

Твои претензии какие-то странные. С одной стороны ты говоришь что активный режим говно с другной стороны бьешся как рыба об лед чтобы доказать что пробрасывать активный режим - привильно. Почему правильно если он говно? Не пробрасывай. Твоя позиция противоречива.

протокол предусматривает защиту от нецелевого использования активного режима?

При чем тут вообще протокол? Описанная уязвимость - не уязвимость FTP софта вообще, и является уязвимостью только в случае если там кто-то чужой делает вид что он FTP. От такого вообще ничто не защищено.

Или покажите мне хотя бы один официальный документ, в котором категорически запрещается использование активного режима в публичных сетях.

Выставляя любой сервис на файрволе в открытый мир ты должен осознавать что делаешь. Если у тебя пароль root/root - это что вина криптоалгоритма?

r ★★★★★ ()
Ответ на: комментарий от nnz

Начнем с простого вопроса: протокол предусматривает защиту от нецелевого использования активного режима? Нет? Значит, это его проблемы.

может быть протокол ещё должен предусматривать защиту от «нецелевого» копирования /etc/shadow, раз уж он занимается передачей файлов?

yekm ()
Ответ на: комментарий от nnz

Если бы они действительно так думали, то обязательно бы запретили использование активного режима в публичных сетях.

Активный режим может использоваться в публичных сетях построенных на реальных IP. Только надо осознавать что делаешь. Активный режим FTP не более опасен чем обычный HTTP сервер. Точно так же как кто-то может сделать вид что он FTP сервер, точно так же ничто не помешает ему повесится и на 80 и на 22 и на любой порт который он найдет доступтупным при предидущем сканировании. Если сисадмин не шарит что у него запущено или как пользоваться файрволом - это проблема сисадмина а не софта.

А работа с серыми айпишниками официально запрещена?

Для нее существует пассивный режим.

r ★★★★★ ()
Ответ на: комментарий от r

>Фактические последствия действий лежат на плечах деятелей. Если деятели думают что микроскоп подходящее для забивания гвоздей действие - ССЗБ.

Лично мне совершенно неинтересно слушать, как вы пытаетесь отмыть одних, обгадив других. Мол, это не баг, а фича (говорят, любимая фраза дядюшки Гейца была в свое время). Мне вообще совершенно не интересно, кто виноват в сложившейся ситуации. Для меня гораздо интереснее варианты выхода из нее.

Перефразируя - клиенты ходят голой жопой в мокрую^W^W открытый интернет. Ну и кто в этом виноват?


Разумеется, протокол, который defective by design.

Direct Connect в IM тоже не безопасен? С фактической стороны он ничем не отличается от активного режима FTP.


Безусловно. А если для него тоже сделают такие обработчики, это вообще песетц будет.

Ну конечно! Интернет придумали для хоумбоев с файлзилами в домашних сетках.


А здесь стоит заметить, что сегодня HTTP является одним из наиболее популярных способов передачи файлов.

В публичную сеть и не надо ходить активным режимом. Активный режим выставляет голую жопу в интернет и не важно стелано это пакетным фильтром или реальным айпишником. Если не знаешь что делаешь - не выставляй.


А почему жопа голая? А потому что FTP^Wштаны дырявые.

Твои претензии какие-то странные. С одной стороны ты говоришь что активный режим говно с другной стороны бьешся как рыба об лед чтобы доказать что пробрасывать активный режим - привильно. Почему правильно если он говно? Не пробрасывай. Твоя позиция противоречива.


Никакого противоречия здесь нет. Это только вам, кабинетным теоретикам, так кажется.
Клиенты хотят, чтобы у них все работало. А мой долг чести и мое начальство хотят, чтобы все работало _безопасно_. Вот и все.

Корень противоречий находится не моей позиции, а в дефектах протокола FTP и иже с ним.

При чем тут вообще протокол? Описанная уязвимость - не уязвимость FTP софта вообще, и является уязвимостью только в случае если там кто-то чужой делает вид что он FTP. От такого вообще ничто не защищено.


Не надо уходить от ответа. Раз официально не запрещено использовать активный режим в публичных сетях, значит (с точки зрения разработчиков софта), его можно и нужно использовать при необходимости. А необходимость есть (из-за медленного и не всегда работающего пассивного режима). И проблемы безопасности их не колышат.

Выставляя любой сервис на файрволе в открытый мир ты должен осознавать что делаешь.


Я делаю так, чтобы FTP работал.

Если у тебя пароль root/root - это что вина криптоалгоритма?


Если система не позволяет поставить другой пароль root — это вина пользователя?

nnz ★★★★ ()
Ответ на: комментарий от r

>Активный режим может использоваться в публичных сетях построенных на реальных IP.

Описанный метод атаки отлично работает даже без ната. Нейтрализация фаервола.

Активный режим FTP не более опасен чем обычный HTTP сервер.


Неа. HTTP не требует для своей работы разблокирования дополнительных портов, т.к. все происходит через одно соединение.
Советую почитать RFC по HTTP ;)

nnz ★★★★ ()
Ответ на: комментарий от nnz

Для меня гораздо интереснее варианты выхода из нее.

Ответ дан в следующем письме по ссылке - не пользуйся пробросом.

Разумеется, протокол, который defective by design.

Замени НАТ-проброс на реальный IP. Любой сервис дефективный потому что для него надо открывать порт который может занять малвара?

Ачнись.

А почему жопа голая?

Нет, потому что ты сознательно открыл файрвол на входящие соединения на машину где серверный порт может открыть шопопало. Чего ты ждал в результате - санта клауса?

Клиенты хотят, чтобы у них все работало.

У них все работает. Passive mode и вперед.

А мой долг чести и мое начальство хотят, чтобы все работало _безопасно_.

В каком месте открытие пробрасываемх серверных портов на машинах где может запускаться что угодно секретаршами и прочими подобными экспертами хотя бы отдаленно касается слова «безопасно»?

Это вообще безотносительно FTP дыра класса кто хочешь заходи чего хочешь бери.

Афтару этого поста уже ткнули носом в очевидные факты. Проблема это не FTP и не нат-пробросов, а головы. Если нат-пробросы рискованы - выключи их. Если есть шанс установким внешних соединений малварой - заведи прокси.

его можно и нужно использовать при необходимости.

Сколько раз говорить - протокол FTP используется не толькодля скачивания последней мозиллы на домашнюю тачку. Его применимость гораздо шире - особенно в корпоративных системах связанных с файлообменом.

Я делаю так, чтобы FTP работал.

Ты разрешаешь входящие соединения на ненадежную машину. ССЗБ. FTP тут не причем. Он тебя не просил такого делать.

Если система не позволяет поставить другой пароль root — это вина пользователя?

PASSIVE MODE!

r ★★★★★ ()
Ответ на: комментарий от nnz

Описанный метод атаки отлично работает даже без ната.

Описанный метод атаки это вообще преодоление ната по сути. Ты что сам не читал что запостил? В этом посте вообще не про фтп а про nat helpers. И этого чудака уже ткнули носом что он предявляет в качестве претензии к натхелперам то что было основной целью их создания.

HTTP не требует для своей работы разблокирования дополнительных портов, т.к. все происходит через одно соединение.

И этот порт может с успехом может занять троян. Что тогда напишешь - HTTP дефективный?

r ★★★★★ ()
Ответ на: комментарий от r

>Ответ дан в следующем письме по ссылке - не пользуйся FTP
fixd

Я бы с радостью. Да юзерам надо.

Замени НАТ-проброс на реальный IP. Любой сервис дефективный потому что для него надо открывать порт который может занять малвара?


Фу. Опять вы скатываетесь в откровенно толстую демагогию. Нужно отличать _ручное_ открытие _заданного_ порта на _сервере_ (каковой порт обычно занимается штатным демоном) от _автоматического_ открытия _произвольного_ порта на _клиенте_. Это две большие разницы, уверяю вас.

Нет, потому что ты сознательно открыл файрвол на входящие соединения на машину где серверный порт может открыть шопопало. Чего ты ждал в результате - санта клауса?


Меня заставили. С ножом у горла. Кривой FTP.

У них все работает. Passive mode и вперед.


У них не работает.
По дефолту включен активный, а как выключить — они не знают.

В каком месте использование FTP на машинах где может запускаться что угодно секретаршами и прочими подобными экспертами хотя бы отдаленно касается слова «безопасно»?

fxd

Вот и я так думаю. А что делать...

Это вообще безотносительно FTP дыра класса кто хочешь заходи чего хочешь бери.


Неправда. Эти дыры специфичны именно для defective by design protocols like FTP and IRC.
Видимо, вы слишком плохо разбираетесь в работе стека TCP/IP, несмотря на ваши неоднократные заявления о чтении RFC.

Сколько раз говорить - протокол FTP используется не толькодля скачивания последней мозиллы на домашнюю тачку. Его применимость гораздо шире -


DDoS атаки и бэкдоры, ага.

Ты разрешаешь входящие соединения на ненадежную машину. ССЗБ. FTP тут не причем. Он тебя не просил такого делать.


Он не просил. Он _требовал_. Иначе он не работает.

PASSIVE MODE!


Не вариант. Я уже объяснял почему.

nnz ★★★★ ()
Ответ на: комментарий от r

>Описанный метод атаки это вообще преодоление ната по сути. Ты что сам не читал что запостил?

Чукча не читатель, чукча писатель.

А вы-то читали?

Заметим, что к данной угрозе чувствительны не только персональные (работающие на клиентском хосте) фаерволы


Самое первое и очевидное назначение — вскрытие индивидуальных фаерволов. А NAT traversal is more complicated application.

И этот порт может с успехом может занять троян. Что тогда напишешь - HTTP дефективный?


Это уже совсем другой разговор. Занять привилегированный порт на сервере, убив штатного демона — это не хухры-мухры. Тут обычно рут нужен.
А послушать пятьдесят тысяч лохматый порт на десктопной машинке любой дурак сможет.

nnz ★★★★ ()
Ответ на: комментарий от yekm

>может быть протокол ещё должен предусматривать защиту от «нецелевого» копирования /etc/shadow, раз уж он занимается передачей файлов?

А зачем? Эта возможность и так заблокирована правами ФС.

Не надоело демагогией заниматься?

nnz ★★★★ ()
Ответ на: комментарий от r

В этом посте вообще не про фтп а про nat helpers.


conntrack_ftp необходим для нормальной работы ftp за простым файрволом. Он очень много где включен по-умолчанию и файрвол редко когда имеет правила, учитывающие работу такого проброса.

Мне казалось, это документированная всем известная фича. Все правила всегда пишутся с учётом этих вещей.


Фича известная, но мало кто о ней задумывается. Поверьте, далеко не все правила пишутся с учетом этих вещей. Я бы даже сказал, подавляющее большинство пишутся без учета. Ничего нового здесь не написано, но напоминание иногда полезно.

troop ()
Ответ на: комментарий от r

дык основная проблема в том, что много где такая конфигурация реально используется, иногда даже эти модули вкомпилированы в ядро. И если взять среднестатистический компьютер с бубунтой и флешем, то очень легко с помощью банальной веб-страницы заюзать данную «фичу»

anonymous ()
Ответ на: комментарий от CyberTribe

> Соотвественно заголовок скорее звучать должен «Архитектурная уязвимость „Активного режима“ протокола ftp», ибо уязвимость там, а не в работе фаерволла. Верно?

Нет. Это именно уязвимость межсетевого экрана, в котором активирована соответствующая функция - возможность установить соединение с защищаемым клиентом, не предусмотренное изначальными правилами.

А вообще, все протоколы с «плавающим» номером порта деффективны «из коробки».

no-dashi ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

>я думаю это проблема софта, выполняющего чужой код — т.е. флеши, явы и возможно браузера

флешь например должна запрещать выполняющемуся под ней коду лезть на те порты, которые приводят к открытию локальных портов и пробросу соединения на них, ну или спрашивать юзера об этом


Самое страшное — это как раз невозможность отличить действия легального клиента от действий малвари.
Ведь даже настоящие сервера могут юзать нестандартные порты для FTP.

nnz ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.