LINUX.ORG.RU
 
nnz

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


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.

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


[#] Ответ на: комментарий от iZEN 28.12.2009 12:33:36  

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

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

**** ()
[#] Ответ на: комментарий от leave 29.12.2009 21:55:04  
nnz

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

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

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


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

**** ()
[#] Ответ на: комментарий от val-amart 29.12.2009 17:33:05  
nnz

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

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

**** ()
[#] Ответ на: комментарий от gloomdemon 29.12.2009 12:49:43  

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

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

***** ()
[#] Ответ на: комментарий от nnz 28.12.2009 21:13:08  

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

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

***## ()
[#] Ответ на: комментарий от nampuapx 29.12.2009 6:02:49  

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

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

***## ()
[#] Ответ на: комментарий от nnz 29.12.2009 23:26:19  
val-amart

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

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

**** ()
[#] Ответ на: комментарий от nnz 28.12.2009 2:26:00  

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

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

* ()
[#] Ответ на: комментарий от val-amart 30.12.2009 1:39:07  
nnz

Спасибо, TERM=xterm-color отлично работает :)

**** ()
[#] Ответ на: комментарий от nnz 30.12.2009 2:06:38  
val-amart

всегда пожалуйста, рад что помогло

**** ()
[#] Ответ на: комментарий от EvgGad_303 29.12.2009 16:17:31  
dhameoelin

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

>>-----Цитата---->>

Цитируем EvgGad_303

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

<<-----Цитата----<<
>>-----Цитата---->>

Цитируем EvgGad_303

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

<<-----Цитата----<<
>>-----Цитата---->>

Цитируем EvgGad_303

на лоре

<<-----Цитата----<<

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

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

* ()
[#] Ответ на: комментарий от AVL2 29.12.2009 14:15:14  

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

**** ()
[#] Ответ на: комментарий от bbk123 30.12.2009 12:00:06  
no-dashi

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

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

***** ()
[#] Ответ на: комментарий от no-dashi 30.12.2009 13:34:36  

А я где-то утверждал, что FTP "являются достаточно безопасными протоколом"?

**** ()
[#] Ответ на: комментарий от bbk123 30.12.2009 14:53:40  
no-dashi

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

***** ()
[#] Ответ на: комментарий от EvgGad_303 30.12.2009 13:37:28  
dhameoelin

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

>>-----Цитата---->>

Цитируем EvgGad_303

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

<<-----Цитата----<<

закроем тему

* ()
[#] Ответ на: комментарий от nnz 29.12.2009 22:24:02  
r

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

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

***** ()
[#] Ответ на: комментарий от no-dashi 30.12.2009 15:06:45  

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

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

**** ()
[#] Ответ на: комментарий от bbk123 31.12.2009 13:31:50  

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

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

***** ()
[#]  

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

***** ()