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

> Вопрос тут в корне - нахрена это нужно чтобы оно работало из-за ната?

Наверное потому, что какие-то идиоты, обчитавшиеся RFC(какой там ты сказал?) начали строить системы и кластеры, а потом пришла ж..па. И еще - даже пассивный режим не позволит тебе написать правило на файрволе. Потому как в ответе на PASV приходит IP-адрес и номер порта. FTP ублюдочен на уровне дизайна.

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

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

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

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

Дык, само собой.

А вот r с этим не согласен.

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

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

Пруф?

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

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

В этом месте можно подробнее? Почему пассивный режим медленее активного?

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

Цитируем nnz

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

осильте доменные политики уже)))

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

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

> осильте доменные политики уже)))

Вы считаете, что все фаерволы в интернете работают под управлением MS Windows ?

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

Цитируем anonymous

Вы считаете, что все фаерволы в интернете работают под управлением MS Windows ?

ящитаю, что клиенты в сети камрада nnz таки вендовые, пусть он меня поправит, если я ошибаюсь

и вообще, это была ирония

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

и вообще, причем тут фаерволы? чукча - пейсатель?

говорилось про то, что клиенты используют активный режим по-умолчани

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

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

Такого нет в протоколе. Там наоборот клиент говорит на какой порт приходить.

gods-little-toy ★★★
()
Ответ на: комментарий от dhameoelin

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

смотря какие, в браузерах ftp:// открывается в пассивном режиме , во всех остальных есть настройки

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

FTP.EXE

кто-то под оффтопиком использует консоль?

я регулярно пользуюсь и именно ftp.exe
консолью тоже часто, многи дела гораздо быстрее через неё чем ждать тормозного explorer.

mumpster ★★★★★
()

kernel/net/netfilter/nf_conntrack_amanda.ko
kernel/net/netfilter/nf_conntrack_pptp.ko
kernel/net/netfilter/nf_conntrack_tftp.ko
kernel/net/netfilter/nf_conntrack_ftp.ko
kernel/net/netfilter/nf_conntrack_h323.ko
kernel/net/netfilter/nf_conntrack_proto_dccp.ko
kernel/net/netfilter/nf_conntrack_netbios_ns.ko
kernel/net/netfilter/nf_conntrack_proto_gre.ko
kernel/net/netfilter/nf_conntrack_sane.ko
kernel/net/netfilter/nf_conntrack_sip.ko
kernel/net/netfilter/nf_conntrack_proto_sctp.ko
kernel/net/netfilter/nf_conntrack_netlink.ko
kernel/net/netfilter/nf_conntrack_irc.ko
kernel/net/netfilter/nf_conntrack_proto_udplite.ko

они все дырявые ? )

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

Почему пассивный режим медленее активного?

ну не всегда.
но быстрее всего противный режим.;)
а если серьёзно - в силу природы, потому что «PASV...requests the server-DTP to „listen“ on a data port and to wait for a connection rather than initiate one upon receipt of a transfer command.» (RFC 959)
Если мальенько пораскинуть мозгами, то понятно почему тормозит при этом, как правило, больше. впрочем, если качать большие (дял Вашего канала) файлы - разница несущественна по-любому.

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

Цитируем Silvy

смотря какие, в браузерах ftp:// открывается в пассивном режиме , во всех остальных есть настройки

ну, Вам мне практически нечем возразить, разве только тем, что /me совершенно не помнит, есть ли у объявленного в треде ftp://ftp.exe какие-либо настройки... не сочтите за троллинг, просто самоирония

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

собственно вот -

~ :$ftp ftp.gnu.org
Connected to ftp.gnu.org (140.186.70.20).
220 GNU FTP server ready.
Name (ftp.gnu.org:sylvia): ftp
530 Please login with USER and PASS.
SSL not available
...
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
500 Illegal PORT command.
ftp: bind: Address already in use
ftp> pass
Passive mode on.
ftp> ls
227 Entering Passive Mode (140,186,70,20,185,17)
150 Here comes the directory listing.
lrwxrwxrwx 1 0 0 8 Aug 20 2004 CRYPTO.README -> .message
...
226 Directory send OK.
ftp>

Sylvia ★★★★★
()

squid

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

Sylvia ★★★★★
()

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

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

as33 ★☆☆
()

объясните кто-нить в чем вобще проблема? не открыл клиент 5000 порт у себя, и фаервол его пробросил, а толку то? соединение то все равно на 5000 порт ловит фтп клиент.

swelf
()
Ответ на: FTP.EXE от mumpster

Цитируем mumpster

кто-то под оффтопиком использует консоль?

я регулярно пользуюсь и именно ftp://ftp.exe консолью тоже часто, многи дела гораздо быстрее через неё чем ждать тормозного explorer.

да я тоже консоль юзаю, но больше батниками

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

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

nnz считает, что ему ничего не будет.

r считает, что отгребет за всех.

По-своему опыту скажу, что обычно чаще всего r ближе к истине.

irek
()

FTP на файрволе лучше всего закрыть вообще. Пароли заснифят >_<

sv75 ★★★★★
()

Ну и какой бонус получит троян(вирус) от дополнительного tcp соединения? На 21 порт он и так имеет выход для пополнения/докачки.

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

> > Почему пассивный режим медленее активного?

ну не всегда.

но быстрее всего противный режим.;)
а если серьёзно - в силу природы, потому что «PASV...requests the server-DTP to „listen“ on a data port and to wait for a connection rather than initiate one upon receipt of a transfer command.» (RFC 959)
Если мальенько пораскинуть мозгами, то понятно почему тормозит при этом, как правило, больше. впрочем, если качать большие (дял Вашего канала) файлы - разница несущественна по-любому.

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

bbk123 ★★★★★
()

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

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

Цитируем irek

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

nnz считает, что ему ничего не будет.

r считает, что отгребет за всех.

По-своему опыту скажу, что обычно чаще всего r ближе к истине.

хмм, боюсь, что

вздрочнут

- это мягко сказано

По-своему опыту скажу, что обычно чаще всего r ближе к истине

по своему опыту - скажу аналогично

dhameoelin ★★★★★
()

Со стороны сервера:
мне казалось, и так оно и есть, что для работы активного режима фтп никакие хелперы не нужны. Пропускаем на сервер 21 порт, и пропускаем все исходящие соединения (плюс пропускаем все установленные соединения). Для пассивного нужен коннтрак-хелпер для открытия порта, на который будет ожидаться коннект от клиента. Но.. кто в этом случае уязвим? фтп-сервер? Ы?

Со стороны клиента с реальным ип:
никаких хелперов для работы активного режима фтп не надо, достаточно разрешить исходящие соединения и входящие с порта 20 (который фтп дата). Для пассивного режима тоже лишних телодвижений не надо, исходящие соединения и так разрешены.

Со стороны клиента за натом:
для пассивного режима нет никаких проблем, исходящие коннекты разрешены. Для активного режима можно использовать хелперы _на шлюзе_, которые обеспечат проброс портов для клиента. Но кто уязвим? Я не совсем понял. Объясните, пожалуйста, еще раз :)

ЗЫ умные люди активный режим на фтп-серверах отключают.

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

> ведь при пассивном режиме FTP на серваке надо пачку портов неприкрытыми держать. А если это shared хостинг сервер, то сколько, извините, геморроя будет стоить вычищение возможности открыть порт любому клиенту?

Эту работу и делает коннтрак-хелпер

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

>Проблема в том, что соединение может инициировать вовсе не ftp-клиент и вовсе не на сервер

а в чем тогда вобще проблема протокола, если на машине уже какашка? если она может сымитировать работу фтп клиента, то она может много чего сделать, тупо обратиться на 80 порт куда надо, и скачать что надо.

swelf
()

Мдя, протоколы далёкого прошлого преподносят сюрпризы :) Ну правильно, 38 лет протоколу :) А вы ещё спрашиваете - кому нужен plan9 :)

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

> ЗЫ умные люди активный режим на фтп-серверах отключают.

Да ну? Зачем его отключать на серверах? Дайте адрес такого сервера.

bbk123 ★★★★★
()

это не баг - это фича , о которой знает любой нормальный админ.

решения:

1. выгрузить фтп хелпер

2. ограничить порты на которые с помошью него можно коннектиться

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m helper --helper ftp -p tcp ! --dport 20480:32768 -j DROP
iptables -A INPUT -m state --state RELATED -j ACCEPT

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

>Эту работу и делает коннтрак-хелпер.

На FTP-сервере?

TOHbl4
()

Коммент «Интернет не нужен» уже был? :)

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

>Когда же FTP станет историей, пароль открытым текстом,

FTP умеет работать с TLS.

вот эта ошибка дизайна активного режима,


Во-первых, разрешать FXP для всего попало - дурной тон. На каждом FTP-сервере и клиенте FXP по умолчанию должен быть отключен, а разрешён только для определённой группы пользователей и IP-адресов (возможно даже со списком разрешённых FXP IP для каждого из них).

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

Итого - это не ошибка дизайна, а ошибка тех, кто всем всё разрешает (и тебе FXP и активный режим и работа всего этого хозяйства через NAT).

низкая производительность,


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

только для домашних нанолокалок (одна квартира) пригоден. А разрабам ipfilter ломать голову теперь надо.


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

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

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

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

Знает знает

> > ftp ( ftp.exe в win32) знает команду PAS (passive)


совершенно не знает.

Не далее как в этом месяце писал прогу которая синхронизовала содержимое катклогов с FTP сервером (ниасилил клиент rsync вот и выбрасывает деньги на написание ненужных граблей). Так вот в ТЗ было чётко сказано нужно чтобы сама работа с ftp велась через ftp.exe а моя прога только запускала оную. Никаких проблем с пассивным режимом (поддержка которого тоже была в ТЗ) не возникло. Только там команда: pasv

А вообще когда IT решения принимаются не IT специалистом маразм заходит и дальше проброски произвольных портов для того, чтобы FTP работал в активном режиме, так как юзеры не знают как переключиться на пассивный режим.

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

> Да ну? Зачем его отключать на серверах? Дайте адрес такого сервера. Сервер, на котором мне такое попалось был локальным, и было это еще года четыре или даже больше назад. Когда я тотал-командером не мог туда подконектица а браузером заходило. Админ (весьма бывалый) сказал, что активный не труЪ и подсказал какую галочку поставить в клиенте чтоб работало. тогда о таких вещах как iptables/conntrack и пр. я мало что знал и поэтому в суть отключения не вник. видимо, причины были.

Эту работу и делает коннтрак-хелпер.

На FTP-сервере?

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

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

спасибо, не знал. есть какие нибудь доки, где подробно описано, как это работает, а то сходу не нагуглилось.

TOHbl4
()

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

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

>осильте доменные политики уже)))

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

Поражают меня некоторые теоретики, консоли не нюхавшие :)

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

>В этом месте можно подробнее? Почему пассивный режим медленее активного?

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

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