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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ПРИКРЕПЛЁННЫЙ ФАЙЛ]
«Центр управления системой» в меню GNOME
Обратите внимание, что меню целиком не помещается на экран, его можно прокрутить, подведя указатель мыши к нижней стрелке).
[ПРИКРЕПЛЁННЫЙ ФАЙЛ]
15_24_45

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

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

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

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

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

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

Объяснение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь картинка с полицейским становится более понятной. Для доступа к серверу по защищённому протоколу требуется получить от него свежезаведённый открытый ключ (в терминах SSL — «серитфикат»), который разумеется, никто не успел подписать. Хуже того. В сертификате, помимо собственно ключа, хранится разнообразная информация о том, кому он принадлежит — в частности, доменное имя сайта. Но к моменту, когда нам необходимо подключиться к веб-интерфейсу на сервере, служба DNS на нём может и не работать, поэтому в примере используется IP-адрес. Обо всём этом (о недоверенности передаваемого сертификата и о несоответствии доменного имени) и сообщает навигатор. Для того, чтобы история впоследствии не повторилась, сертификат надо запасти на будущее (это называется «подтвердить исключение безопасности».

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

Теперь пару слов о «настройке сети для класса». Собственно, ничего таинственного в них нет, нам необходимо воспользоваться двумя службами сервера: службой автоматизации клиентских настроек DHCP (Dynamic Host Configuring Protocol) и межсетевым экраном с маршрутизацией.

Сначала о маршрутизации. Вообще говоря, свойство быть маршрутизатором — принимать чужие пакеты и перенаправлять их через другой сетевой интерфейс — ядру Linux присуще, однако его следует включать специальной настройкой ядра sysctl (net.ipv4.ip_forward; в дистрибутивах Пятой Платформы можно также выставить эту настройку в единицу в файле /etc/net/sysctl.conf). В сервере она включена по умолчанию, но задачу «настройки сети для класса» это может решить только в случае, когда всем компьютерам раздаются настоящие IP-адреса. Точнее говоря, когда эти адреса обрабатываются не нашим сервером, а где-то дальше, сервер же попросту маршрутизирует пакеты от абонентов своей локальной сети. В нашем случае это не так: диапазон адресов в локальной сети был выбран вполне произвольно, следовательно, нам и отвечать за то, чтобы в дальнейшем своём путешествии по сети Интернет эти пакеты были признаны годными.

Просто так пакеты из настраиваемой локальной сети годными признаны не будут: они принадлежат одному из так называемых «внутренних» диапазонов адресов, именно: 10.0.0.0/8. Пакеты с такими адресами в глобальной сети недопустимы, задача сервера — преобразовать их во что-либо пригодное. Например, воспользоваться умением межсетевого экрана Linux — IPTables — осуществлять трансляцию сетевых адресов (NAT, Network Address Translation). Суть метода в том, что при пересылке пакетов «в большую сеть» адрес отправителя в них подменяется на адрес сервера (этот адрес, очевидно, работоспособный). Если предполагается обмен данными, то каждый сеанс обмена запоминается межсетевым экраном (например, для TCP-соединения запоминается адрес и порт настоящего отправителя, адрес и порт получателя, а также порт отправителя, выданный сервером в результате трансляции) и, проанализировав входящий трафик, сервер принимает решение об обратном преобразовании.

Команда iptables-save на сервере покажет, что преобразование адресов происходит в правиле таблицы nat подсистемы IPTables -A POSTROUTING -o breth0 -j MASQUERADE. Правило означает буквально, что после того, как принято решение о маршрутизации пакета (пакет предназначен куда-то вовне, и передаётся через сетевой интерфейс breth0), содержимое пакета обрабатывается специальной цепочкой-действием MASQUERADE. В отличие от цепочки-действия NAT, преобразующий адрес в некоторый заранее заданный, MASQUERADE сначала получает адрес соответствующего сетевого интерфейса, и преобразует именно в него. Это потребляет чуть больше ресурсов, чем NAT, зато правильно работает в ситуации, когда этот адрес настраивается динамически (как в нашем примере).

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

CategoryP5