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 ()
Ответ на: комментарий от r

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

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

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

Не было бы костылей в виде ната и все было бы хорошо. Так что не спорьте товарищи!! во всем виноват IPv4)))

programmist
()
Ответ на: комментарий от fank

>на каждый файл отдельное соединение????

А что, какие-то клиенты по умолчанию работают иначе?

богохульник!!!!


Культ FTP? :)

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

>капитан очевидность подсказывает, что такое сделано с целью экономии ресурсов сервера

У меня такое чувство, что вашему капитану далеко не все очевидно, раз он так сильно бросается из крайности в крайность. Гоните его нафиг, это самозванец ;)

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

TCPDUMP

ты tcpdump-то хоть раз запускал при обмене по ftp? запусти и удивись.

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

кстати, предлагаю немножко повзрослеть и перестать отвечать за всех

в треде никто не привел ссылку на статистику по дефолтным режимам для клиентов

fank
()
Ответ на: комментарий от programmist

конечной точкой в этой логической цепочке точно будет инертность человеческого мышления, так что ты не угадал =)

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

>кстати, предлагаю немножко повзрослеть

Ну, у кого что чешется :)

перестать отвечать за всех


Налицо попытка отрицания объективной реальности.

в треде никто не привел ссылку на статистику по дефолтным режимам для клиентов


Если вы этого не знаете и вам это интересно — займитесь исследованиями.
А опытные админы и так знают, как все на самом деле, и у них достоверность статистических оценок вопросов не вызывает.

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

это ты типа про себя так сказал

ну похвалил себя, точно

P.S. жесть.

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

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

одна из причин

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

> > Во первых не все люди, а лишь создатели программ.

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


Этого более чем достаточно если знать причину, по которой они это делают. Ты этой причины не знаешь.

> Во вторых, почему ты решил, что они это делают из-за скорости?


А почему еще? Других вариантов я не вижу.


Если ты считаешь, что дело в скорости, ты должен это доказать.

> Согласись, что «неоднократно слышал мнение» - не аргумент.


Разумеется, само по себе это не аргумент, а лишь часть аргумента. Голословное утверждение, не подтверждаемое на практике, ничего не стоит. Но в данном случае подтверждение как раз-таки есть.


Какое подтверждение? Ты до сих пор не удосужился просто скачать с FTP сервера один и тот же файл несколько раз в активном и в пассивном режимах что бы сравнить скорости. О чём ещё с тобой можно спорить? О неоднократно слышанном мнении?

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


Вполне логично и очевидно. Но кто сказал, что технические условия работы соединения являются единственным фактором, влияющим на скорость передачи данных? Может, серверам религ^WRFC предписывает по пассивным соединениям данные медленно отдавать? (Самый простой вариант навскидку :))


Детский сад.

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


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


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

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

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

Как ни странно причина та же - историческая. Изначально протокол FTP не имел пассивного режима вовсе. Поэтому даже после выхода RFC 959 существовали FTP сервера, пассивного режима не поддерживающие. При этом практически все современные браузеры, по умолчанию, работают с FTP в пассивном режиме.

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

>Этого более чем достаточно если знать причину, по которой они это делают. Ты этой причины не знаешь.

Но могу предполагать.

Если ты считаешь, что дело в скорости, ты должен это доказать.


Если вы считаете, что дело НЕ в скорости, вы должны это доказать :)

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


Готовая инструкция по некорректному тестированию.
Очень часто пользователи качают более одного файла, и очень часто ситуация на маршруте значительно отличается от тепличных условий с клиентом и сервером в одной локалке (а пусть даже и ftp.kernel.org).

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


Нет. Это _ваша_ логика, логика гротескных ситуаций и некорректных параллелей.

Как ни странно причина та же - историческая.


Как я уже сказал, это объяснение представляется мне неудовлетворительным. Даже _современные_ FTP-клиенты по умолчанию используют активный режим. Лет 10-20 назад я бы его принял :)

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

> > разницы в скорости не должно быть никакой. Опишите ваш расклад.

внимательно читаем ещё раз. потом думаем, рисуем диаграммку протокола в том и другом случае. потом представляем себе, ну например, не dial-up. но gprs - и медленно понимаем разницу между немедленным SYN port 20 и wait от клиента только после подтверждения. конечно, с учётом реалий grps.;-) ещё раз подчеркну - при закачке больших (по отношению к скорости канал) - разницы особой нет. но если качаешь много мелких файлов - разница существенна.


Кто на ком стоял? Потрудитесь излагать свои мысли яснее.

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

> > Этого более чем достаточно если знать причину, по которой они это делают. Ты этой причины не знаешь.

Но могу предполагать.


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

> Если ты считаешь, что дело в скорости, ты должен это доказать.


Если вы считаете, что дело НЕ в скорости, вы должны это доказать :)


Бремя доказательства лежит на том, кто утверждает.

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


Готовая инструкция по некорректному тестированию.

Очень часто пользователи качают более одного файла, и очень часто ситуация на маршруте значительно отличается от тепличных условий с клиентом и сервером в одной локалке (а пусть даже и ftp.kernel.org).

Скачай в локалке или скачай с ftp.kernel.org много раз в каждом из режимов. Когда будут результаты, приходи.

> Сторона вождения в разных странах выбиралась исторически и в большенстве стран она правая. Но следуя твоей логике это обязательно должно быть связано со скоростью.


Нет. Это _ваша_ логика, логика гротескных ситуаций и некорректных параллелей.


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

> Как ни странно причина та же - историческая.


Как я уже сказал, это объяснение представляется мне неудовлетворительным. Даже _современные_ FTP-клиенты по умолчанию используют активный режим. Лет 10-20 назад я бы его принял :)


Считай это традицией.

bbk123 ★★★★★
()

Копипаст с опеннета, для тех кт ов танке

Попробую популярно объяснить, что это такое. Юзер заходит браузером на страничку хакера. У него в браузере выполняется JS скрипт. Этот JS скрипт стучится на сервер хакера, на 21 порт.

Скрипт шлет команды: USER anonymous PASS test@example.com PORT 192,168,1,2,1,189

Роутер юзера видит (за счет nf_conntrack_ftp), что юзер говорит FTP серверу: «Подключайся ко мне, на ip адрес 192.168.1.2 и на порт 445». 445 порт - это 1*256 + 189 (последние числа в команде PORT).

Роутер думает «Бедный юзер, FTP сервер не сможет до него достучаться. Ведь юзер за натом.». И переделывает команду «PORT 192,168,1,2,1,189» в команду «PORT 8,8,8,8,201,128». Где, 8.8.8.8 - это внешний ip адрес роутера (допустим). А 201,128 - это значит порт 51584 (201*256 + 128). А ещё добрый роутер делает временный проброс порта 51584 на адрес 192.168.1.2 и порт 445.

Сервер хакера (который слушает на 21 порту) получает команду «PORT 8,8,8,8,201,128». И пытается ткнуться на ip адрес 8.8.8.8 и порт 51584. Добрый роутер пробрасывает это соединение. И сервер хакера без особых усилий достукивается до порта 445 юзера с ip адресом 192.168.1.2.

А дальше уже все зависит от умений и знаний хакера. Можно не только на 445 порт подключаться, а на любой. У винды «открытые веселые порты» есть с номерами больше 1024.

Как вы можете видеть, атака НЕ зависит от включения/выключения ftp протокола на компьютере клиента. FTP клиентом выступает JS скрипт в браузере юзера.

Если у юзера роутер - это ваш сервер, то конечно можно принять меры. Поставить frox, сделать правила iptables или ещё чего. Или можно тупо вырубить nf_conntrack_ftp.

А что можно сделать, если у юзера роутер - железка, в которой до настройки фаерволла не добраться? «не надо юзать дешевые железки» - не вариант. Как вариант - все-таки включать брандмауэр виндовс.

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

дык все думают коль за натом, нафига он мне ?

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

>капитан очевидность мне подсказывает, что пассивный режим появился после того, как отдельные люди осознали конечность множества ИП адресов и придумали НАТ

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

AVL2 ★★★★★
()

Это печально

Данный мегасрач войдет в историю как «война активов с пассивами»

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

> пассивный режим был создан тогда, когда люди осознали, что безопасный сервер не должен инициировать коннекты сам. Это опасно и не нужно.

В 1985 году?

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

> sshfs , правда не совсем кроссплатформенно

что заначит «не совсем кроссплатформенно»? мобильник на javame не поддерживает?

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

> Юзер заходит браузером на страничку хакера. У него в браузере выполняется JS скрипт. Этот JS скрипт стучится на сервер хакера, на 21 порт.

Есть маленькая проблемка, не все броузеры поддерживают сокеты, а уж тем более дают их просто так юзать. Та же мозилла при использовании nsISocketTransportService жутко орет. Хотя есть еще flash =)

А вообще виноваты те, кто настраивают на такую работу машрутизатор. Есть passive ftp и все. Проблема высосана из пальца, а всем кто так делает желаю тогда вообще открыть все порты на проброс и выложить свой адрес в инет, а то подавай им active ftp, видите ли.

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

>Скрипт шлет команды: USER anonymous PASS test@example.com PORT 192,168,1,2,1,189

С этого места по-подробнее! Каким это образом js может работать с сокетами?

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

да фиг бы с ним, с js... есть же быдлофлеш

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

> сходи что-ли почитай как tcp/ip работает, ламерок

Ты наверное не в курсе, но TCP/IP, TCP и IP это три разных человека :-) Иди учись дальше, красноглазик.

нат он для всего работает «из коробки»

Ладно. Покажи как SIP работает через NAT без conntrack'а или аналогичной технологии. Просим, просим. Да, SIP-сервер не должен строить предположений о реальном адресе, а брать то, что содержится в полученных от клиента данных.

no-dashi ★★★★★
()

Вот читаю-читаю тред.. Этот модуль что, не умеет сделать типа `nf_conntrack_ftp --dont-open 0-1024`? А если нет, то что, допилить сложно? И овцы сыты, и волки целы. Номер локального порта полагаю в начальном запросе можно изменить, пусть и костылем в фаере, не?

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

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

А неплавающие можно, если что, зарезать на ура, и буду я сидеть без любимого порно по торренту. Так что плавающий порт не баг, а фича ;)

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

>С тем же успехом я могу предположить, что твои волосы выкрашены в зелёный цвет.

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

Бремя доказательства лежит на том, кто утверждает.


Ну так вы же утверждаете, что я неправ :)

Скачай в локалке или скачай с ftp.kernel.org много раз в каждом из режимов. Когда будут результаты, приходи.


Скажу честно и откровенно: лень. Гораздо веселее сраться целый день на форуме, чем проверять на практике откровенно сомнительные тезисы ;)

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


И все-таки ваши аналогии представляются мне некорректными.

Считай это традицией.


Традиции бывают полезные и вредные. В такой агрессивной среде, как интернет, вредные традиции живут недолго.

Ну да ладно.

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

В общем, считайте, что я признал слабость своей аргументации и согласился с вашей точкой зрения.

nnz ★★★★
() автор топика

срут, срут, уже 4 страницы насрали. неужели еще никто не сказал, что проблема высосона из [s]залупы[/s] пальца.

зачем мне, как разработчику мелвари, заниматься геморроем с пробросом ftp, sip и т.д. портов на локальную машину, если моя мелварь УЖЕ находится на этой самой машине и может непосредственно обратиться к локальному порту и слить весь трафик на удаленный сервер БЕЗ УСТАНОВКИ дополнительного соединения со стороны сервера, ась?

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

неужели еще никто не сказал, что проблема высосона из залупы пальца.

я осознал. Точнее, предположил. Но тут позже упомянули какие-то мозилловские приблуды для работы с сокетами из js, а также есть флеш.

legolegs ★★★★★
()

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

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

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

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

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

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

val-amart ★★★★★
()
Ответ на: комментарий от iZEN

> Очнитесь, люди. Зачем в локалке FTP? NFS и CIFS будут быстрее в РАЗЫ!

Интересно, как это у тебя получается? У меня в локалке FTP быстрее, чем NFS (немного) и Samba (значительно).

nampuapx
()
Ответ на: комментарий от legolegs

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

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

>Есть passive ftp и все

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от val-amart

>вполне себе обычный. в терминологии сокетов есть понятие активного и пассивного установления соединения.

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

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

>Более-менее нагруженном серверу не хватит портов.

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

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

> не подскажешь, как мне так сделать, если за натом более 1 машины? :)

Черт =) Сделай смещение начиная с 10001 порта, т.е. вторая тачка начинается 10001 -> 1. Как ни странно, выше обычно ничего интересного даже если ssh переставляют руками.

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

> если моя мелварь УЖЕ находится на этой самой машине и может непосредственно обратиться к локальному порту и слить весь трафик на удаленный сервер БЕЗ УСТАНОВКИ дополнительного соединения со стороны сервера, ась?

Блин, выше же написали классный usecase.

gloomdemon
()
Ответ на: комментарий от DonkeyHot

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

Черт, а что же я без проблем захожу на ftp.freebsd.org? Или у freebsd все так плохо?

gloomdemon
()

>используя технологии XMLHTTPRequest

А про Same Origin Policy товарищи не слышали?

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

>зачем мне, как разработчику мелвари, заниматься геморроем с пробросом ftp, sip и т.д. портов на локальную машину, если моя мелварь УЖЕ находится на этой самой машине и может непосредственно обратиться к локальному порту и слить весь трафик на удаленный сервер БЕЗ УСТАНОВКИ дополнительного соединения со стороны сервера, ась?

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

Все должно быть секурно. Ты грузишь апплет с сайта www.site.ru. Этот апплет посылает пакет, например с очками на тот же самый сайт www.site.ru и попутно открывает порт извне, а там уже совсем другие программы используют открытый порт извне.

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

>В 1985 году?

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

AVL2 ★★★★★
()

Спасибо за способ обхода закона

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

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

> Видимо, он используется главным образом среди программеров.

ну да ;) пассивное, это когда приложение вызывает listen(), а активное - когда connect()

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

ненене, всё выставлять, так всё, вплоть до 65к :)

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

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

а что, self-signed уже совсем никак? или там использовать сертификат для https/smpt/pop3?

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