Differences between revisions 30 and 31
Revision 30 as of 2009-12-07 01:25:47
Size: 23409
Editor: FrBrGeorge
Comment:
Revision 31 as of 2009-12-07 14:05:05
Size: 29015
Editor: FrBrGeorge
Comment:
Deletions are marked like this. Additions are marked like this.
Line 109: Line 109:
Второе затруднение значительней, вокруг него и весь сыр-бор. Для того, чтобы безопасно передавать данные, необходим открытый ключ получателя. А этот ключ, в свою очередь, необходимо ''безопасно'' передать отправителю. Иначе доступ Второе затруднение значительней, вокруг него и весь сыр-бор. Для того, чтобы безопасно передавать данные, необходим открытый ключ получателя. А этот ключ, в свою очередь, необходимо ''безопасно'' передать отправителю. Получается дурная бесконечность: для организации безопасного соединения необходимо... заранее организованное безопасное соединение. Правда, для передачи ключа безопасность надо соблюсти лишь однократно, но отказываться от мер предосторожности нельзя: должна быть гарантия, что полученный ключ ''действительно'' принадлежит отправителю, а не какому-нибудь злоумышленнику, получившему доступ к среде передачи данных.

Если принимать на веру подлинность полученного открытого ключа, злоумышленник, технически способный перехватить пересылаемые данные и подменить их своими, может запросто расшифровать эти данные так, что и отправитель, и получатель этого не заметят. Традиционный (и единственный сравнительно простой) способ называется [[../KeywordАтакаManInTheMiddle|атакой «man-in-the-middle»]] («человек посередине»). Суть её очень проста: вместо того, чтобы позволить получателю переслать ключ, а отправителю — шифровать им данные, злоумышленник ретранслирует поток данных через свой компьютер, попутно их расшифровывая. Более подробно: открытый ключ получателя злоумышленник вообще не показывает отправителю, а отсылает ему ''свой'' открытый ключ. Отправитель, думая, что разговаривает непосредственно с получателем, шифрует этим ключом свои данные, злоумышленник их перехватывает, расшифровывает (атака прошла успешно!), затем шифрует ключом получателя и отправляет ему, чтобы не вызывать подозрений.

Если не рассматривать передачу ключа альтернативными способами (например, можно приехать к администратору сайта, и лично у него переписать этот ключ), есть два способа избежать обмана, когда открытый ключ передаётся в рамках того же, ещё не доверенного, соединения. Первый состоит в том, чтобы, получив ключ, проверить его аутентичность (опять-таки с помощью альтернативного канала передачи данных). В этом помогает так называемый «[[../KeywordОтпечатокПальца|отпечаток пальца]]» (fingerprint) — некоторое число, которому однозначно соответствует открытый ключ. Это число достаточно велико, и алгоритм его получения достаточно сложен, так что у злоумышленника нет разумной возможности изготовить ''свой'' ключ с таким же отпечатком. При этом отпечаток намного меньше самого ключа, и человек в состоянии самостоятельно сличить два отпечатка: тот, что сгенерирован из полученного ключа, и тот, что опубликован на сайте, или в службе DNS или получен иным способом. Предполагается, что злоумышленник не готов тратить столько ресурсов, чтобы получать контроль над всеми видами передачи данных.

Другой способ — воспользоваться электронной подписью. Если на компьютере отправителя имеется некоторый ''проверенный'' открытый ключ, получатель может попросить хозяина этого ключа подписать ключ получателя перед пересылкой. Тогда отправитель увидит, что пришедшая информация подписана доверенным лицом, и, стало быть, после того, как её подписали, не менялась. В действительности это род бизнеса: договариваться с производителями дистрибутивов ОС и ПО, использующего SSL, о том, чтобы включать в них свои открытые ключи, а затем брать деньги за подписывание этими ключами (точнее, их закрытыми парами).

Самозарождение порядка

Ситуация и её описание

Для того, чтобы решить задачу, которая очевидно проступает в нашем рассказе, её сначала нужно сформулировать. В согласии с классическими традициями, опишем, что дано, что требуется и в каких условиях решение будет считаться удовлетворительным. Упоминание об условиях не случайно. Очень многие задачи «из жизни» не имеют окончательного решения: почти всегда есть возможность улучшить то, что уже имеется, и почти всегда выбор — останавливаться ли на пути улучшения или идти дальше — упирается в наличие ресурсов: времени, квалификации, средств. Мы ограничимся тем, что опишем условия, в которых задача посчитается решённой и потеряет для нас исследовательский интерес.

Дано
  • Функционирующая локальная сеть с одним концентратором, объединяющая рабочие места и серверную комнату
  • Доступ в сеть Интернет из серверной комнаты в виде сетевого кабеля и инструкции по настройке сетевых параметров
  • Компьютер произвольной вычислительной мощности, предназначенный на роль сервера
  • Компьютер(ы) произвольной вычислительной мощности, предназначенные для рабочих станций
Требуется
  • Организовать возможность полноценной работы сервера и рабочей станции (выход в Интернет, управление сервером)

Условия
  • На серверный компьютер установлен дистрибутив «Альт Линукс Ковчег 5.0 Сервер», подключение к сети Интернет настроено а процессе установки таким образом, что единственный »внешнийЮ» IP-адрес приходится на серверный компьютер
  • Сервер имеет два сетевых интерфейса: «нулевой» — для подключения к сети Интернет, и «первый» — для взаимодействия с локальной сетью
  • На рабочую станцию установлен дистрибутив «Альт Линукс Ковчег 5.0 Рабочая Станция»
  • Процесс установки ОС можно не описывать, т. к. он описан в руководстве по установке
  • Доступа к серверу со стороны «внешнего» адреса на момент решения задачи нет

Решение задачи

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

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

  • Внешний адрес, адрес DNS-сервера и адрес маршрутизатора по умолчанию сервер получает автоматически, для этого используется сетевой интерфейс breth0.

  • Внутренняя подсеть выбирается произвольно, например 10.30.50.1/24, где 10.30.50.1 — адрес внутреннего сетевого интерфейса на сервере(breth), а 24 — размер сетевой маски в локальной сети. Далее мы всегда будем пользоваться адресом 10.30.50.1 в качестве адреса сервера.

  • Сеть на рабочей станции ещё не настроена, но имя компьютера задано (например, автоматически)

Что уже произошло

Согласно допущению из условий задачи, операционная система установлена и на сервер, и на рабочую станцию, все кабели подсоединены, подключение сервера к сети Интернет настроено (автоматически).

«Альт Линукс Ковчег 5.0 Сервер» непосредственно после установки нуждается в начальной настройке — следует задать учётную запись суперпользователя, унифицированное имя домена и некоторую другую информацию. Руководство по установке даёт простую и однозначную картину: после перезагрузки сервер опубликует на системной консоли адрес веб-интерфейса для управления, на него следует зайти с помощью любого навигатора по адресу http://10.30.50.1:8080.

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

Временная настройка клиентской машины

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

Настройки рабочей станции будем менять с помощью локальной версии Центра Управления Системой (ЦУС), которая присутствует во всех дистрибутивах Пятой платформы. В дистрибутиве «Альт Линукс Ковчег 5.0 Рабочая Станция» программа доступна в меню GNOME: Система -> Параметры -> Центр управления системой:

[ATTACH]
«Центр управления системой» в меню GNOME
Обратите внимание, что меню целиком не помещается на экран, его можно прокрутить, подведя указатель мыши к нижней стрелке).
[ATTACH]
15_24_45
  • 15_25_14 [ATTACH]

  • 15_30_00 [ATTACH]

  • Где найти документацию? http://$IP_ADDR [ATTACH]

Настройка сервера

  • 15_41_20 [ATTACH]

  • 15_42_12 [ATTACH]

Заминка с сертификатом

  • 15_43_10 [ATTACH]

  • 15_43_34 [ATTACH]

  • 15_43_54 [ATTACH]

Начальная настройка сервера

  • 15_45_34 [ATTACH]

  • 15_50_47 [ATTACH]

  • Подключение к интернету настроено [ATTACH]

Автоматическая настройка сетевых установок в локальной сети

  • 15_53_52 [ATTACH]

  • 15_54_53 [ATTACH]

Финальная настройка клиентской машины

  • 16_00_09 [ATTACH]

Настройка межсетевого экрана в режиме трансляции адресов

  • 16_02_05 [ATTACH]

  • 16_02_41 [ATTACH]

  • 16_03_11 [ATTACH]

Объяснение

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

А ларчик просто не открывался

Ни то, ни другое. Просто руководство по установке решает принципиально другу задачу: описать установку ПО на сервере, и только её. В нашем же случае речь зашла о настройке работоспособной локальной сети, что поднимает задачу определения сетевых серверных настроек. Кроме того, дополнительное требование «вакуума на площадке» приводит к необходимости настраивать рабочее место параллельно серверу. Наконец, здоровая человеческая предусмотрительность, требующая, чтобы учётные данные (пароль суперпользователя!) передавались по сети только по защищённому соединению, нашла на не менее здоровую человеческую предупредительность, которая поставила под сомнение сам факт защищённости этого соединения.

Но обо всём по порядку.

Без окон, без дверей

Традиционно принято различать в Linux тесктовые системные консоли и графическую подсистему. В дистрибутиве «Альт Линукс Ковчег 5.0 Сервер» графическая подсистема используется только на этапе установки; собственно, в состав ПО, устанавливаемого на сервер, она не входит. Таким образом после установки серверной части мы получаем компьютер, работа с которым возможна только посредством текстовой консоли — либо через веб-интерфейс, если настроена сеть. Учитывая особенность серверного оборудования нещадно шуметь и находиться в труднодоступной серверной комнате (не говоря уже об удалённых площадках), такой минимализм вполне оправдан.

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

Следовательно, процесс установки сервера требует (как то и сказано в руководстве по установке), чтобы был второй компьютер, рабочее место администратора, с которого можно было бы завершить первоначальную настойку и начать основную. Но, как выясняется, простой установки веб-навигатора недостаточно: требуется настроить доступ по сети хотя бы к самому серверу, то есть присвоить рабочей станции IP-адрес из одной с сервером подсети. Здесь мы столкнёмся с некоторой особенностью: конфигуратор не соглашается применять сетевые настройки, если они не полны, именно: не содержат т. н. «шлюза по умолчанию» (это поле можно на первых порах заполнять как угодно, но обычно роль шлюза по умолчанию как раз выполняет сервер).

Кто проверяет проверяльщика?

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

Сам протокол HTTP, посредством которого навигатор обменивается данными с сервером, вполне текстовый; искушённые администраторы способны получить текст страницы с сервера вообще безо всякого навигатора, вводя HTTP-запросы вручную с помощью команды непосредственного подключения к порту (например, netcat). Что более важно, вся информация передаётся в нём в открытую, без шифрования. Строго говоря, даже если шифровать передаваемые данные с помощью информации, передаваемой в том же соединении, перехватить и расшифровать эти данные будет не сложнее, чем перехватить нешифрованые. Поэтому — если уж скрывать содержимое передаваемых данных, например, имя пользователя и пароль, от посторонних глаз — следует заранее позаботиться о том, чтобы как минимум не клиентской имелась какая-то информация о сервере, с помощью которой данные получилось бы зашифровать так, что только на сервере их было возможно расшифровать.

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

Этого как раз и требуется достичь! Используемый протокол-надстройка Secure Socket Layser (SSL) организует на обоих концах потока данных TCP шифрующие-дешифрующие «фильтры», а программа знай себе шлёт в этом потоке свои данные. Затруднения только два. Первое: поскольку шифрование не поднимается на прикладной уровень, необходимо как-то различать шифрованные и нешифрованные потоки данных на уровне транспортном. Это легко устранить, договорившись, что для использования SSL приложение подключается к серверу по другому порту, например, научить навигатор вместо 80-го порта заходить на 443-й. С точки зрения навигатора это вообще воспринимается как новый сетевой протокол (https: вместо http:).

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

Если принимать на веру подлинность полученного открытого ключа, злоумышленник, технически способный перехватить пересылаемые данные и подменить их своими, может запросто расшифровать эти данные так, что и отправитель, и получатель этого не заметят. Традиционный (и единственный сравнительно простой) способ называется атакой «man-in-the-middle» («человек посередине»). Суть её очень проста: вместо того, чтобы позволить получателю переслать ключ, а отправителю — шифровать им данные, злоумышленник ретранслирует поток данных через свой компьютер, попутно их расшифровывая. Более подробно: открытый ключ получателя злоумышленник вообще не показывает отправителю, а отсылает ему свой открытый ключ. Отправитель, думая, что разговаривает непосредственно с получателем, шифрует этим ключом свои данные, злоумышленник их перехватывает, расшифровывает (атака прошла успешно!), затем шифрует ключом получателя и отправляет ему, чтобы не вызывать подозрений.

Если не рассматривать передачу ключа альтернативными способами (например, можно приехать к администратору сайта, и лично у него переписать этот ключ), есть два способа избежать обмана, когда открытый ключ передаётся в рамках того же, ещё не доверенного, соединения. Первый состоит в том, чтобы, получив ключ, проверить его аутентичность (опять-таки с помощью альтернативного канала передачи данных). В этом помогает так называемый «отпечаток пальца» (fingerprint) — некоторое число, которому однозначно соответствует открытый ключ. Это число достаточно велико, и алгоритм его получения достаточно сложен, так что у злоумышленника нет разумной возможности изготовить свой ключ с таким же отпечатком. При этом отпечаток намного меньше самого ключа, и человек в состоянии самостоятельно сличить два отпечатка: тот, что сгенерирован из полученного ключа, и тот, что опубликован на сайте, или в службе DNS или получен иным способом. Предполагается, что злоумышленник не готов тратить столько ресурсов, чтобы получать контроль над всеми видами передачи данных.

Другой способ — воспользоваться электронной подписью. Если на компьютере отправителя имеется некоторый проверенный открытый ключ, получатель может попросить хозяина этого ключа подписать ключ получателя перед пересылкой. Тогда отправитель увидит, что пришедшая информация подписана доверенным лицом, и, стало быть, после того, как её подписали, не менялась. В действительности это род бизнеса: договариваться с производителями дистрибутивов ОС и ПО, использующего SSL, о том, чтобы включать в них свои открытые ключи, а затем брать деньги за подписывание этими ключами (точнее, их закрытыми парами).

Всех выпускать, никого не впускать

CategoryP5

FrBrGeorge/BookP5/ComplexWay (last edited 2009-12-12 21:47:12 by FrBrGeorge)