Кратко

  • RFC 1273 в 1991 году описал план шести прогонов в 1992-м: программа должна была проверять 13 TCP-служб примерно в 12 700 доменах. Это был не готовый результат годового наблюдения.
  • Успешное соединение сразу закрывали без прикладных данных. Отказ и тайм-аут вели к разным ограничениям, поэтому ни один исход сам по себе не доказывал пригодность службы, безопасность, намерение организации или причину отключения.
  • Индивидуальные уведомления создали больше сетевой и административной нагрузки, чем измерение; широкое объявление могло менять поведение, а персональное разрешение—состав выборки. План связал предварительную публикацию, узнаваемый источник, отказ от участия и агрегированный вывод.

Сначала зафиксировали способ получить ответ

Прогоны планировались на январь, март, май, июль, сентябрь и ноябрь 1992 года, по одному-два дня. Информационный RFC вышел в ноябре 1991-го. Он не сообщал, как за год изменилась доступность служб, потому что этого наблюдения ещё не было.

Зато он делал проверяемым будущий инструмент. Около 12 700 доменов, службы daytime, netstat, FTP, Telnet, SMTP, DNS, Finger, Sun portmap, rlogin, rsh, UUCP, klogin и krcmd или kshell. Исследование выбирало доступность на уровне служб, а не базовую IP-связность.

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

Соединение не превращалось в использование

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

Успех означал только принятие соединения данной целью в данный момент. Он не подтверждал вход, доступ к файлу, доставку почты, правильный ответ, право использования или деловой результат.

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

Менее навязчивой альтернативой могли быть DNS-записи Well Known Service. Документ счёл их неполными и несогласованными: для работы сети они не требовались. Запись каталога и активная попытка соединения были разными свидетельствами и ошибались по-разному.

Ограничения определяли форму данных

После успеха программу больше не интересовала та же служба в домене до конца прогона. Пределы отказов и тайм-аутов сокращали бесполезную нагрузку. Расчётный максимум составлял 37 запросов соединения на домен.

В августе 1991 года тест выполнил 50 549 DNS-запросов и 73 760 попыток соединения примерно за десять часов. Одновременно шло не более двадцати сетевых операций. Сбор управлялся из одной точки, ход и нагрузка наблюдались, процесс можно было быстро остановить.

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

Объяснение опыта стало воздействием

Первые уведомления распространялись через alt.security и индивидуальную почту. Около половины писем администраторам вернулись как недоставленные. По RFC 1273, сетевые и административные издержки объявлений значительно превысили издержки измерения; некоторые площадки считали само письмо лишней тратой времени.

Широкое объявление могло побудить площадку изменить доступность служб. Индивидуальное согласие создало бы самовыбранную группу, вероятно, менее склонную отключаться. Процедура легитимации одновременно становилась фактором выборки.

Это не отменяло полномочия оператора. RFC 1262 сохранял общую границу минимального воздействия, контакта с провайдерами и явного разрешения перед чрезмерной удалённой нагрузкой. Конкретный план RFC 1273 включал заблаговременную публикацию, сообщения в списках, учётную запись testnet, сведения через Finger, прямой адрес исследователя и удаление площадки по просьбе.

Трассируемость не доказывала, что каждый получил уведомление. Она давала заметившему активность возможность определить источник, задать вопрос и прекратить участие своего сайта.

Сырые точки не должны были стать публичной картой

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

Основной источник статьи—RFC 1273. RFC 1262 используется лишь для соседней общей границы. Источники не содержат законченной годовой серии, не доказывают выполнение графика 1992 года и не устанавливают причину изменения служб.

Историческая сила RFC 1273 в порядке публикации: метод стал видимым раньше вывода. Будущий график уже не мог честно представить выборку, пробу, нагрузку, уведомление, отказ от участия и хранение как один неразделимый факт.