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

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

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

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



Нет, что вы! Я так вовсе не считаю.
Проблема есть, и игнорировать ее нельзя.

Но есть еще пара вопросов — кто создал проблему, и могут ли с той стороны возникнуть другие проблемы. Ответы: FTP, да.

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

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

Какой же ты упрямый красноглазый неуч. Тебе уже 20 раз объяснили где проблема, а ты все задом виляешь «нет, это не я».

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

>> Пруф?

ЕМНИП, Phrack номер 65, пятая статья, Clawing holes in NAT with UPnP. Release date : 11/04/2008.



Не знаю, что там случилось с официальным сайтом, но счастливым пользователям gentoo для прочтения достаточно выполнить две команды:

# emerge -avt =phrack-65
$ less /usr/share/doc/phrack/p65_0x05_Clawing\ holes\ in\ NAT\ with\ UPnP_by_FelineMenace.txt.bz2

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

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

Знаешь, сколько «любых» портов открывает средний клиент для удалённого взлома, и насколько просто открыть соединение с 20го порта на контролируемой машине?

Для пассивного режима тоже лишних телодвижений не надо, исходящие соединения и так разрешены

и ботнетские агенты тоже обычно установлены.

Но кто уязвим?

Клиент уязвим. Достаточно заставить web-клиента открыть соединение на порт 21 сервера взломщика (обычно разрешено, да?) и передать туда «PORT самый-уязвимый-из-локальных-сервисов, который, вероятно, ещё и с неограниченными привилегиями работает. И все дружественные firewall-ы автомагически открывают доступ взломщику туда, куда он захотел.

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

>ЕМНИП, Phrack номер 65, пятая статья, Clawing holes in NAT with UPnP. Release date : 11/04/2008.

«URL недействителен и не может быть загружен»

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

Цитируем nnz

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

*понюхал консоль, скривился* - вендовая плохо пахнет, буду дома - понюхаю убунтовскую

Цитируем nnz

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

алиасами обойтись для того же фтп-клиента - совсем никак?

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

Такая проблема зеркало поискать? Я вот в портажах всё нашёл. О чём выше и написал.

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

>Достаточно заставить web-клиента открыть соединение на порт 21 сервера взломщика (обычно разрешено, да?) и передать туда «PORT самый-уязвимый-из-локальных-сервисов

Но ведь порт выбирается клиентом! А если клиент не скомпроментирован, то он передаст серверу номер того порта, который смог забиндить сам. А если клиент сам по себе троянец, то он может организовать проксю (пассивную) наружу и без всяких conntrack. Или я что-то не понял?

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

>> Когда же FTP станет историей, пароль открытым текстом, вот эта ошибка дизайна активного режима, низкая производительность, только для домашних нанолокалок (одна квартира) пригоден. А разрабам ipfilter ломать голову теперь надо.

Даже для квартиры SFTP как-то сподручнее — речь не о том, что шифрованное, а о том, что детских болезней FTP нет. Ну и еще HTTP + надстройки над ним.


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

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

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

А я откуда знаю, почему?


Хорошо, почему ты решил, что пассивный режим медленее?

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


Не знаю откуда у тебя такая статистика. Но какое отношение это имеет к заданному мной вопросу?

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

>черт, туплю, проехали

Ну ладно, проехали так проехали :)

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

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

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


Какой-то сервак в какой-то локалке - вовсе не показатель. Даже если этот админ имеет большой авторитет в местной общаге. Из твоего рассказа вообще не понятно почему не работал активный режим.

Я знаю ровно одну причину по которой активный режим может быть ограничен (запрет FXP), но не отключён полностью. Таким образом предотвращается использование FTP сервера для анонимного сканирования портов.

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

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

А сколько клиентов из активно используемых сейчас поддерживают FTPS?

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

Во-первых, разрешать FXP - дурной тон

fixd

FXP не нужен. Уже лет десять как. С тех пор, как появилась возможность сделать
ssh user1@host1 «scp file user2@host2:/path»
Это и надежнее (два соединения вместо трех), и безопаснее (нативное шифрование трафика, возможность автоматической авторизации по ключам).

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


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

Так что это все-таки design error. Ибо у SFTP почему-то таких проблем нет в принципе.

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


И на многих корпоративных шлюзах, вы не поверите! Не говоря уже о домашних роутерах.

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

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

А причём тут юниксовый ftp, когда ты говорил про "ftp.exe в win32"? И почему ты решил, что тебя, с твоим предложением скачать нормальный ftp клиент, обязательно послушают?

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

>Хорошо, почему ты решил, что пассивный режим медленее?

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

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

Но какое отношение это имеет к заданному мной вопросу?


Есть такая штука — логика, да. Но пытаться что-то объяснить тому, кто этого слова не понимает бессмысленно.

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

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

man iptables (но там очень скудно) и какие-нибудь netfilter documentation.

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

nnz, ты еще тот неуч.

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

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

r в споре с тобой был абсолютно прав.

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

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

1) исторически пассивный режим появился позже, поэтому он второй в очереди.

2) пассивный режим надо включать и не везде он включен по умолчанию.

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

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

AVL2 ★★★★★
()

Нужна просто альтернатива ftp... мне в ftp не нра практически отсудствие подержки utf8.
CIFS, NFS не предлагать это немного не то.

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

>А причём тут юниксовый ftp, когда ты говорил про "ftp.exe в win32"? И почему ты решил, что тебя, с твоим предложением скачать нормальный ftp клиент, обязательно послушают?

ftp> literal pasv 227 Entering Passive Mode (192,168,1,1,126,80)

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

>Нужна просто альтернатива ftp... мне в ftp не нра практически отсудствие подержки utf8.

CIFS, NFS не предлагать это немного не то.

оная в ftp давно уже запилена. man rfc2640

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

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

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

windows, macos и linux реализации есть.

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

> Клиент уязвим. Достаточно заставить web-клиента открыть соединение на порт 21 сервера взломщика (обычно разрешено, да?) и передать туда «PORT самый-уязвимый-из-локальных-сервисов, который, вероятно, ещё и с неограниченными привилегиями работает. И все дружественные firewall-ы автомагически открывают доступ взломщику туда, куда он захотел.

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

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

>Решается просто. Ручками закрываются нужные порты.

Что решается?

AVL2 ★★★★★
()

(Вытирая слезы платочком) автор, лови плюс в карму за содержание и оформление/грамматику. Приятно читать.

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

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

Я бы сказал, что ты идиот, но скорей всего ты просто неграмотен. Тебе точно также трахаться с поддержкой пассивного режима через NAT. Или ты будешь разрешать весь исходящий TCP?

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

> А если клиент сам по себе троянец, то он может организовать проксю (пассивную) наружу и без всяких conntrack. Или я что-то не понял?

Именно, ты не понял. Злонамеренная программа может сказать PORT 192,168,1,1,5,241 - и файрвол приготовится к пробросу на 1521 порт (Oracle TNS Listener). А он совсем дырявый. Дальнейший сценарий описать?

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

>Злонамеренная программа может сказать PORT 192,168,1,1,5,241 - и файрвол приготовится к пробросу на 1521 порт (Oracle TNS Listener). А он совсем дырявый.

А что мешает злонамеренной программе самой законнектиться на этот 1521?

legolegs ★★★★★
()

Мда, ТТ. proftpd уже давно умеет работать с NAT корректно и в любом режиме. Те, кто указывает использовать порты пересекающиеся с другими демонами либо идиот, либо гений :)

Ref:
http://www.proftpd.org/docs/howto/NAT.html

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

>Из этого становится ясно что все твои знания о FTP основываются на мнениях каких-то там людей, которые наверное также о FTP мало чего знают.

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

nnz, ты еще тот неуч.

Ты сперва изучи что в RFC написано, потом будешь с умными людьми спорить.



Роль почетного неуча в данном случае выполняет как раз r, который, несмотря на заверения в чтении RFC, похоже, плохо представляет себе принципы работы стека TCP/IP (достаточно почитать его реплики в конце первой страницы). А я в этом вопросе худо-бедно разбираюсь, к его несчастью.

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

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

В общем, слив засчитан.

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

>1) исторически пассивный режим появился позже, поэтому он второй в очереди.

Вот это выглядит достаточно убедительно.

2) пассивный режим надо включать и не везде он включен по умолчанию.


А это уже очевидное следствие.

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


Да, вот с такими коррективами — согласен :)

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

> Именно, ты не понял. Злонамеренная программа может сказать PORT 192,168,1,1,5,241 - и файрвол приготовится к пробросу на 1521 порт (Oracle TNS Listener). А он совсем дырявый. Дальнейший сценарий описать?

У мея нету Oracle на машине, с которой я конекчусь по ftp. Думаю, что у 99,9% клиентов то же самое.

Что мешает, запретить файрволу проброс соединений на порты, для которых этот прброс опасен/не предназначен?

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

> У мея нету Oracle на машине, с которой я конекчусь по ftp. Думаю, что у 99,9% клиентов то же самое.

Зато у тебя есть например порт 139. Или 443. Был бы компьютер, а порт найдется.

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

>у тебя есть например порт 139

это такой тонкий намек на UA ? ))

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

Да это был феерический пердёж. Я такого ахтунга мало где видел. Бедный r не вынес ЭТОГО! Да и у меня честно говоря 'руки опустились' ЭТО читать. nnz - это просто вынос мозга, я вам доложу. Небыдло?

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

> > Хорошо, почему ты решил, что пассивный режим медленее?

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


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

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


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

> Но какое отношение это имеет к заданному мной вопросу?


Есть такая штука — логика, да. Но пытаться что-то объяснить тому, кто этого слова не понимает бессмысленно.


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

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

>Я бы сказал, что ты идиот, но скорей всего ты просто неграмотен

нет ты

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

Тебе точно также трахаться с поддержкой пассивного режима через NAT


нат он для всего работает «из коробки» - для irc к примеру, стыдно такого не знать. сходи что-ли почитай как tcp/ip работает, ламерок

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

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

Про подтверждение это вы жжоте. Как там в интернетах (ЩИТО?). Ну из ваших потов непременно следует, что обсуждаемые здесь два связанных TCP стека, так не не дошли до вашего сознания. И да, не только вам открылось откровение TCP стека.

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

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

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

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


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

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


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

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


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

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


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

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

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

> > А причём тут юниксовый ftp, когда ты говорил про "ftp.exe в win32"? И почему ты решил, что тебя, с твоим предложением скачать нормальный ftp клиент, обязательно послушают?

ftp> literal pasv 227 Entering Passive Mode (192,168,1,1,126,80)


Долго искал literal? Осталось научить ftp.exe поддерживать этот режим в таких командах как ls, dir, get, put, mget, mput.

bbk123 ★★★★★
()

Надо же, а ведь кто-то разрабатывал ftp_conntrack... И такая банальная «недекларированная возможность», это первое, что должно было придти в голову...

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

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

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

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

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

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

про скорость это ты точно отжег, даже не отрицай

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

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

Ну и как это относится к теме? Преимущественное использование активного режима по умолчанию продолжается и по сей день.

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