ANTICHAT — форум по информационной безопасности, OSINT и технологиям
ANTICHAT — русскоязычное сообщество по безопасности, OSINT и программированию.
Форум ранее работал на доменах antichat.ru, antichat.com и antichat.club,
и теперь снова доступен на новом адресе —
forum.antichat.xyz.
Форум восстановлен и продолжает развитие: доступны архивные темы, добавляются новые обсуждения и материалы.
⚠️ Старые аккаунты восстановить невозможно — необходимо зарегистрироваться заново.
 |
Угроза безопасности, создаваемая отслеживанием связанных соединений на фаерволе |

28.12.2009, 05:27
|
|
Постоянный
Регистрация: 18.11.2009
Сообщений: 709
Провел на форуме: 1410429
Репутация:
214
|
|
Угроза безопасности, создаваемая отслеживанием связанных соединений на фаерволе
На днях в рассылке разработчиков 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.
|
|
|

28.12.2009, 06:32
|
|
Moderator - Level 7
Регистрация: 24.04.2009
Сообщений: 1,730
Провел на форуме: 30140275
Репутация:
3256
|
|
Ну как бы..в чём тут изначально новость непонятно (поправьте, если вдруг ошибаюсь), это известные вещи, например, мне это известно на протоколе IRC..
P.S.
Сообщение от lukmus
На днях в рассылке разработчиков netfilter/iptables появилось сообщение, рассказывающее об угрозах..
Если только в качестве обзора..
Почитав оригинал, более понятнее стало в чём цель подобного..
http://marc.info/?l=netfilter-devel&...0148319485&w=2
Последний раз редактировалось [Suicide]; 28.12.2009 в 06:46..
|
|
|

28.12.2009, 10:58
|
|
Голос разума
Регистрация: 27.09.2006
Сообщений: 529
Провел на форуме: 1607210
Репутация:
1617
|
|
ну вот на примере outpost firewall для винды, я такого не наблюдал , файр в режиме обучения прилежно спрашивает разрешения для открытия порта, следовательно проблема решаема.
__________________
Бойтесь своих желаний. Они могут исполниться....
...О-о-о-о, ушами не услышать, глазами не понять!
|
|
|

28.12.2009, 11:21
|
|
Участник форума
Регистрация: 04.01.2008
Сообщений: 186
Провел на форуме: 872350
Репутация:
72
|
|
файр в режиме обучения прилежно спрашивает разрешения для открытия порта
а на нормальном режиме (блокировать все что не разрешено) ничего не выйдет.
а под тот же линух если будет такой очень интерактивный фаервол то это вобще не айс 
|
|
|

29.12.2009, 09:35
|
|
Постоянный
Регистрация: 14.04.2008
Сообщений: 327
Провел на форуме: 584699
Репутация:
69
|
|
SQLHACK И как интересно аутспот научиться рандомные порты когда нужно открывать? 
|
|
|

29.12.2009, 10:50
|
|
Участник форума
Регистрация: 06.03.2006
Сообщений: 122
Провел на форуме: 709545
Репутация:
72
|
|
SQLHACK, это тока
Что не есть проблемой для любого фаера.
Пока вывод один: или passive mode или не фтп 
|
|
|

29.12.2009, 11:37
|
|
Участник форума
Регистрация: 27.03.2008
Сообщений: 288
Провел на форуме: 800727
Репутация:
83
|
|
Ещё холивара нам не хватало
А по существу: конечно неприятно, однако я считаю, что по крайней мере, половина защиты системы лежит на человеке, так что надо быть бдительными, господа, а ни в коем случае не винить разработчиков.
|
|
|
|
 |
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
|
|
|
|