Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>Я знаю, я знаю!!

AS>идеальный протокол вместо ftp — это WebDAV over https

AS>1. можно обходить каталоги (вглубь и как угодно)
AS>2. потенциально поддерживает версионирование
AS>3. есть шифрование
AS>4. возможно сжатие при передаче
AS>5. поддерживается в интерфейсе windows (web-folders называется)

Все подводные камни WebDAV отловил?

Здравствуйте, okman, Вы писали:

ДД>>Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.

O>Ну так речь же не о том, сложно или не сложно использовать протокол практически, как с
O>помощью библиотек, а о сложности самого протокола. Не могу сказать, что USB в этом
O>плане простой. И такие вещи, как virtual com, появились, видимо, тоже неспроста,
O>потому что программировать COM существенно проще.

Скорее потому, что были уже готовые и отлаженные средства, которым надо было всего лишь подменить идентификацию порта. А дальше работало как всё привычное.
Конечно, переходить после этого на сложные технологии вроде "найти устройство, открыть endpoint, создать канал, посылать что-то по этому каналу" сильно сложнее.

Здравствуйте, okman, Вы писали:

O>>>Не зная протокола ? Я так не могу.
N>>Действия послать порцию октетов и получить ответ достаточно просты, чтобы не лезть в детали протокола.
O>Идея была в том, чтобы осилить протокол USB, решая одну из базовых задач.
O>Честно признаюсь — мне это не удалось. Перечитал Агурова и pdf-ки с usb.org почти все,
O>наверное, а в голове по-прежнему каша. Как все эти descriptors и reports связаны, и
O>как эта вся кухня работает — не понял.

Гм... ты, наверно, не изучал SIP или H.323. Вот там действительно сложно. USB по сравнению с этим, конечно, путано описывается, но достаточно просто и прямолинейно.

Все эти reports и descriptors — стандартные структуры данных для стандартных целей. Метод общения достаточно прост и понятен. Изучаешь, что к тебе подключилось, чуть подстраиваешь по необходимости, открываешь связи и работаешь.

O> Поэтому после USB такие протоколы, как FTP, кажутся
O>элементарщиной. А пользоваться либами, не постигнув сути происходящего, мне неинтересно.
O>Лучше я помучаюсь еще какое-то время, "созрею", а потом возьму, да и осилю.

Up to you.

Здравствуйте, ononim, Вы писали:

Q>>Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.
O>"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло.

Если доступ к какому-то ресурсу в принципе недопустим с определённых адресов, то зачем надеяться на IDS?

Q>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
O>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.

Однократные токены.

O>Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция.

Проблема именно в авторизации действия по такому соединению к кому-то другому.

Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей.

Причем здесь сабж, и сказать что хотел?

Здравствуйте, quwy, Вы писали:

N>>Что именно не нравится?
Q>Так написали же. Проблемы с кодировками; наличие двух каналов связи, один из которых изначально устанавливался от сервера к клиенту; пассивный режим, требующий дополнительных портов и сокетов.

Идея понятна. А теперь подумай, пожалуйста, вот о чём:
1. Бинарное мультиплексирование — возможно, но не подходит по стилю реализации. Реализация должна была быть настолько проста, чтобы пригодна к диагностике и/или аварийному использованию через простейший telnet.
2. Текстовое мультиплексирование приводит к чему-то вроде нынешнего HTTP, но с определёнными проблемами. Например, неудобно каждый раз задавать контекст. Бинарные данные передавать в тексте — сорвёт крышу подложке. Конверсия в текстово-совместимый формат типа base64 — дорого во всех смыслах. Более того, как выцепить поток данных из переговоров данных по HTTP, видимых в telnet? Как его потом конвертировать и, главное, зачем требовать этого? А в случае отдельного соединения это тривиально — данные просто выливаются в файл или берутся из файла.

Да, сейчас хорошо сравнивать с HTTP. Для которого уже наделали клиентов всех видов. Особенно если WebDAV, как тут упоминали рядом. А тогда? Нормальная реализация HTTP требует больше памяти, чем могла себе позволить типичная машинка того времени.

Проблемы с кодировками — кодировками чего? Файлов? Их вообще-то нет, если платформа не извращённая, как Windows (с различием text/binary) или что-то 36-битное. Имён файлов? Да, проблема была, но возникла только за счёт поспешного решения 8-битных кодировок в exUSSR и аналогичных местах.
Сейчас нормальные клиенты и серверы используют только UTF-8 и проблемы нет, по крайней мере пока не вмешиваются заморочки Unicode (типа разложить символ на codepoints или собрать в один), от которых никто нигде не защищён.

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

N>>Отдельным каналом для данных? SCTP не было.
Q>Отдельный канал не нужен при обычном TCP (и даже UDP).

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

Здравствуйте, quwy, Вы писали:

Q>Здравствуйте, ononim, Вы писали:

O>>>>Какие нить аргументы против этой фичи кроме "негоже" есть?
Q>>>NAT и firewall.
O>>Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP
Q>Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.

Ну так во времена Arpanet ещё и портов то небыло. Какие ещё firewall? Они привет уже из восьмидесятых.

O>>"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло.
>Если доступ к какому-то ресурсу в принципе недопустим с определённых адресов, то зачем надеяться на IDS?
Чтобы доступ к ресурсу был недопустим — нужно убрать ресурс как таковой. Чтобы он был допустим только для определенных сетей — забиндить его на интерфейсы которые смотрят только в те определенные сети. Разграничивать доступ по IPшникам которые являются частью большой сети (интернета) ваще малоосмысленное с ТЗ секурити занятие. Разве что от DOSа. Но от DOSа если блокировать IPшник — то ваще все с него, а не определенные порты.
Да и в конце то концов — все видимые сервисы должны быть в определенном диапазоне, остальное — динамические порты, которые являются частью прикладных протоколов, дело файрволла — разграничивать доступ к сервисам, если он в прикладных протоколах этих сервисов ни бумбум — значит он не должен соваться глубже, разграничивая доступы к динамическому диапазону.

Q>>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
O>>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.
N>Однократные токены.
Дающий однократно одному фтп серверу полный доступ на уровне текущего логина к другому? Это мало чем лучше от знания логина/пароля. Или один раз не ... — будет служить основой секурити?

O>>Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция.
N>Проблема именно в авторизации действия по такому соединению к кому-то другому.
N>Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей.
Костыль ради того чтоб работали какието то быдлоFW и быдлоNAT которые не знают про FTP, который был придуман до FW и NAT?

Здравствуйте, ononim, Вы писали:

O>>>"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло.
>>Если доступ к какому-то ресурсу в принципе недопустим с определённых адресов, то зачем надеяться на IDS?
O>Чтобы доступ к ресурсу был недопустим — нужно убрать ресурс как таковой. Чтобы он был допустим только для определенных сетей — забиндить его на интерфейсы которые смотрят только в те определенные сети.

Пусть сеть A имеет право на доступ к ресурсу, а сеть B — нет. При этом обе сети находятся за маршрутизатором и видны данному серверу через eth1. Как будешь управлять биндингом?
А через фильтр с разграничением по IP и ingress filtering на маршрутизаторе, не пропускающем пакеты с левых сетей — получается надёжная и гарантированная защита.
Почему я должен отказываться от подобных схем ради странной теории?

O> Разграничивать доступ по IPшникам которые являются частью большой сети (интернета) ваще малоосмысленное с ТЗ секурити занятие. Разве что от DOSа. Но от DOSа если блокировать IPшник — то ваще все с него, а не определенные порты.

Во-первых, я говорил про интранет. Во-вторых, и в случае интернета есть существенная разница. Когда я работал в ISP, мы в принципе давали доступ к smtp.lucky.net только с адресов нашей автономной системы (и пары других AS, с которыми были договора об этом). Если кому-то нужно было прийти извне с авторизацией — он шёл на auth-smtp.lucky.net, на котором такого разграничения не было, но на письмо обязательно требовалась авторизация. Вот этот доступ уже был открыт всем, но своя IDS контролировала диверсии против этого адреса (которых, на самом деле, по факту так ни одной и не произошло — ибо неуловимый Джо). Это при том, что физически они сидели на одном хосте — но логически их было удобнее разделить на разные сущности со своими IP адресами. Аналогично было с несколькими другими сервисами.

O>Да и в конце то концов — все видимые сервисы должны быть в определенном диапазоне, остальное — динамические порты, которые являются частью прикладных протоколов, дело файрволла — разграничивать доступ к сервисам, если он в прикладных протоколах этих сервисов ни бумбум — значит он не должен соваться глубже, разграничивая доступы к динамическому диапазону.

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

Q>>>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
O>>>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.
N>>Однократные токены.
O>Дающий однократно одному фтп серверу полный доступ на уровне текущего логина к другому? Это мало чем лучше от знания логина/пароля. Или один раз не ... — будет служить основой секурити?

А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути.

O>>>Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция.
N>>Проблема именно в авторизации действия по такому соединению к кому-то другому.
N>>Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей.
O>Костыль ради того чтоб работали какието то быдлоFW и быдлоNAT которые не знают про FTP, который был придуман до FW и NAT?

Нет, речь не про файрволл или NAT. Речь, например, про рассылку спама. Пишется файл, состоящий из строк:

MAIL FROM:<адрес>
RCPT TO:<адрес>
...
DATA
текст письма
.
RSET
QUIT

дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года.

Q>>>>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
O>>>>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.
N>>>Однократные токены.
O>>Дающий однократно одному фтп серверу полный доступ на уровне текущего логина к другому? Это мало чем лучше от знания логина/пароля. Или один раз не ... — будет служить основой секурити?
N>А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути.
Идя по такому пути в конце концов образом мы изобретем FTP-over-FTP туннель, сделав из FTP сервера еще и прокси И все это ради быдлофрйрволлов

N>>>Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей.
O>>Костыль ради того чтоб работали какието то быдлоFW и быдлоNAT которые не знают про FTP, который был придуман до FW и NAT?
N>Нет, речь не про файрволл или NAT. Речь, например, про рассылку спама. Пишется файл, состоящий из строк:
N>..
N>дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года.
Само собой слышал. Нефиг раздавать доступ к FTP акаунту к серверу с такой возможностью. Вы бы еще шелл раздавали под анонимусом с полным доступом к инету и потом жаловались что оттуда спам шлют.

Здравствуйте, quwy, Вы писали:

Q>Вот меня всегда интересовало, а какой дурень придумал протокол FTP?
Так это было в 70-х годах прошлого века. Предполагалось, что им пользоваться будут иногда ручками через терминал. Всё удобнее чем telnet. Он же не думал, что через столько лет найдуться дурни, которые им будут пользоваться, и тем более что будет столько дурней! Автор FTP думал, что мы уже создадим первую колонию на Марсе и освоим управляемый термоядерный синтез к 2010-му году. Вместо этого по фтп к 2012 году уже перекачаны 100500 тысяч экзобайтов всякого хлама.

Здравствуйте, quwy, Вы писали:

Q>Причем здесь сабж, и сказать что хотел?

очевидно, хотел похвастаться умением писать заголовки без ошибок

Здравствуйте, netch80, Вы писали:

N>Пусть сеть A имеет право на доступ к ресурсу, а сеть B — нет. При этом обе сети находятся за маршрутизатором и видны данному серверу через eth1. Как будешь управлять биндингом?

Биндить не по имени интерфейса, а по адресу.

А я ведь говорил, что 90% линуксового десктопного софта -- это недоделанный постоянно глючащий хлам.
Вон, даже у гуру-линуксоида не работает нормально.

Здравствуйте, ДимДимыч, Вы писали:

N>>Пусть сеть A имеет право на доступ к ресурсу, а сеть B — нет. При этом обе сети находятся за маршрутизатором и видны данному серверу через eth1. Как будешь управлять биндингом?
ДД>Биндить не по имени интерфейса, а по адресу.

Адрес у данного интерфейса только один. Как уже сказано, две других сети за *маршрутизатором*.
Ещё предложения?

Здравствуйте, ononim, Вы писали:

N>>А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути.
O>Идя по такому пути в конце концов образом мы изобретем FTP-over-FTP туннель, сделав из FTP сервера еще и прокси И все это ради быдлофрйрволлов

Нет, вопрос не в файрволлах, а как раз в доверии в открытой сети.

N>>дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года.
O>Само собой слышал. Нефиг раздавать доступ к FTP акаунту к серверу с такой возможностью.

То есть теперь ещё надо следить за комбинацией фич, выданных юзеру или какой-то группе? Одним — с разрешением канала данных к другому клиенту, другим — класть файлы, и следить, чтобы одни с другими не сговорились? Не проще ли разрешить фичу, но с адекватными техническими ограничениями?

O> Вы бы еще шелл раздавали под анонимусом с полным доступом к инету и потом жаловались что оттуда спам шлют.

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

N>>>А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути.
O>>Идя по такому пути в конце концов образом мы изобретем FTP-over-FTP туннель, сделав из FTP сервера еще и прокси И все это ради быдлофрйрволлов
N>Нет, вопрос не в файрволлах, а как раз в доверии в открытой сети.
Один сервер другому может не доверять. Причем объектом защиты безопасности может быть как файлы на другом сервере, так даже и имена/пути под которыми файл с одного сервера мы сохраняем на другой. Если мы хотим дать админам возможность качать майло с сервера на сервер имея на руках лишь модемный\gprs канал — надо в любом случае реализовывать server<->server interconnectivity. То есть один из серверов должен будет являться клиентом. Что собственно и было сделано уже в виде passive/active и к чему одноразовыее токены ничего не добавят в плане функционала, тк все равно будет режим когда сервер является клиентом.
Вся разница решения-нагромождения в виде однократного токена по сравнению с тем что есть — это то что это просто неявно сделает active режим тока режимом между серверами. Сейчас это отдано на откуп админам сервера и юзера — юзать ли клиентам active. А ваше решение — дополнить стандарт мегафичей которая по сути просто лишит их этого выбора и добавит геморроя имплементаторам.

N>>>дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года.
O>>Само собой слышал. Нефиг раздавать доступ к FTP акаунту к серверу с такой возможностью.
N>То есть теперь ещё надо следить за комбинацией фич, выданных юзеру или какой-то группе? Одним — с разрешением канала данных к другому клиенту, другим — класть файлы, и следить, чтобы одни с другими не сговорились? Не проще ли разрешить фичу, но с адекватными техническими ограничениями?
Нет не проще. Проще сделать простую и надежную как молоток техническую фичу, а как и по чем стучать этим молотком — забота админа. В FTP еще кстати есть команда site — ее возможности тоже различаются между разными юзерами, если админ адекватен.

O>> Вы бы еще шелл раздавали под анонимусом с полным доступом к инету и потом жаловались что оттуда спам шлют.
N>Не вижу никакой связи и думаю, что Вы привели аналогию чисто для красного словца.
Нет не для красного словца. Аналогия простая — есть мощная фича которую мона применять как админы для пользы так и хакеры во вред. Юзерам простым она воще не нужна. Потому ее нуна разрешать тока доверенным юзерам/админам, как и шелл, как впрочем нынче дела и обстоят, что создают обманчивое впечатление у большинства участвующих тут юзеров, что такой фичи ваще не существует. Она существует, просто для админов. А FTP никогда и не был user-friendly протоколом, это таки протокол для админов.