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 ()

Ответ на: комментарий от iZEN

>NFS и CIFS будут быстрее в РАЗЫ!

дооо, особенно CIFS. напомни, это то поделие, реализованное на уровне ядра, которое укладывает на лопатки пустой 2xDual Xeon с 8 гигами мозгов при попытке скачать с него dvd-iso в 3 потока?

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

>а что, self-signed уже совсем никак?

Если использовать self-signed, и клиент не хранит копию сертификата у себя, то этот расклад вполне допускает man in the middle. Т.е. по сути такая же голая задница, как и вообще без TLS.

или там использовать сертификат для https/smpt/pop3?


Ну, в принципе можно. Но секурнее все-таки для каждой задачи/группы серверов свой сертификат. Сайту — один, почтовикам другой, для FTP третий.

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

Кстати, сорри за злостный оффтоп, но ты случайно не знаешь, почему цвета в консоли по SSH из линуха к OpenBSD не работают? TERM=xterm, с другими осями все нормально. При установке TERM=cons25 цвет появляется, но вместе с ним и артефакты. Гугл молчит :(

Просто тему влом создавать :)

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

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

Почему-то мне в последнее время не кажется, что 16 бит на номер порта это так уж много. Не знаю почему, у меня больше 10к пока не было. Не ftp, но и ресурс не публичный, т.ч. who его knows, как оно в инете было бы.

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

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

Ок, слив засчитан.

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

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

Откуда такие вопросы? Это же иЗЕНЬ - известный мудозвон:)

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

случайно знаю ;)

дефолтная запись termcap для xterm в Опене не включает возможности цвета. попробуй xterm-color или xterm-xfree86, по крайней мере xterm-color у меня нормально из tmux'а в линуксе работал. а артефакты в конс25 скорее всего потому, что это древняя запись, и например может колбаситься от юникода.

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

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

Безграмотный хаброид детектед ;-)

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

Цитируем EvgGad_303

ну репутация на лоре ни о чем не говорит ;)

Цитируем EvgGad_303

репутация на лоре

Цитируем EvgGad_303

на лоре

Да причём тут ЛОР вообще?

Включите мозг, пожалуйста

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

Если бы дело обстояло так, то активный режим был бы полностью запрещён или по крайней мере объявлен небезопасным. Но в RFC 959 нет ни одного упоминания слов secure, security.

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

> Но в RFC 959 нет ни одного упоминания слов secure, security.

Ты знаешь, в RFC 821 тоже нет ни одного вхождения буквосочетания secur, да и в RFC 854 secur не встречается ни разу. Но это не означает, что SMTP и TELNET являются достаточно безопасными протоколами.

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

Цитируем EvgGad_303

о какой тогда репутации речь? вы знакомы лично?

закроем тему

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

Если использовать self-signed, и клиент не хранит копию сертификата у себя, то этот расклад вполне допускает man in the middle. Т.е. по сути такая же голая задница, как и вообще без TLS.

Разница между self-signed и не self-signed всего одна - есть ли у клиента проинсталированный CA.

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

> Вообще-то, это ты сказал, что активный режим не опасен, поскольку в RFC 959 нет слов secure и security :-)

Вообще-то я этого не говорил. Я отвечал на заявление AVL2 о том, что: «пассивный режим был создан тогда, когда люди осознали, что безопасный сервер не должен инициировать коннекты сам». Пассивный режим появился в 1985 году в RFC 959, но к безопасности не имеет никакого отношения. По крайней мере в тексте этого RFC.

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

>Пассивный режим появился в 1985 году в RFC 959, но к безопасности не имеет никакого отношения. По крайней мере в тексте этого RFC.

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

AVL2 ★★★★★
()

сферический конь в вакууме

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