Smart Cloud

В серии статей под этим названием мы покажем, как установить и сконфигурировать виртуальный сервер в "облаке" компании Rackspace, поделимся собственным опытом и расскажем о нюансах работы с таким сервером. В прошлой статье мы сделали обзор панели управления виртуальными серверами, научились создавать серверы нужной конфигурации, отслеживать их состояние, делать резервные копии, опробовали доступ к серверу с помощью веб-консоли. Тема безопасности сервера важна начиная с момента его создания, чему мы и посвящаем эту статью. В ней будут затронуты (полу-)автоматические обновления, базовая сетевая защита и тонкая настройка доступа по защищенному каналу с помощью SSH.

7. Безопасность с первых шагов.

В прошлый раз было показано, как обеспечить минимальную защиту виртуального сервера от взлома. Во-первых, был создан непривилегированный пользователь, угадать имя и пароль которого труднее, чем просто угадывать пароль администратора. Во-вторых, был полностью деактивирован вход администратора по сети или через виртуальную консоль путем опустошения файла /etc/securetty . Этот файл имеет простой формат - точки входа, разрешенные для пользователя root. Для выполнения администратрских задач достаточно воспользоваться командой "su -" как обычный пользователь или настроить программу sudo. Кстати, если Вы хотите какому-либо пользователю дать привилегии на выполнение отдельных задач администрирования, без последней не обойтись. Настройки /etc/securetty игнорируются службой SSH, но у последней есть свои, что будет видно чуть ниже.

7.1 Удаленный доступ через SSH.

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

1. Служба SSH принимает соединения от удаленных пользователей по порту 22, что можно проверить с помощью нехитрой команды netstat -anptu :
   
   В полученном списке нас интересуют локальные адреса служб в виде IP адреса и порта (Local Address), а также названия служб (PID/Program name). Адреса в виде 0.0.0.0 означают, что служба с соответствующим названием открыта для использования всей сети Интернет, 173.203.100.231 - это интерфейс нашей внешней сетевой карты, адрес, по которому мы собственно зашли на сервер. Службы, которые должны быть доступны только локальным пользователям сервера, такие как базы данных, имеют привязку к локальному адресу 127.0.0.1 (в спивске пока нет). Очень важно следить за тем, какие службы открыты всему миру, а какие - только программам и пользователям внутри сервера. В дальнейшем будет показано, как с помощью брандмауера (файервола) настроить защиту служб от неавторизованного доступа из вне.
   
2. Попробуем обезопасить уже существующую и запущенную службу - SSH. Во первых, сменим порт, по которому SSH принимает соединения снаружи, - это уменьшит количество хулиганов, запускающих программы взлома по стандартным портам служб. Если посмотреть в файл /etc/services, то можно увидеть невероятное количество стандартизированных привязок портов к конкретным службам. Возьмем неиспользуемую службу, точнее ее порт, и заставим SSH с ним работать вместо стандартного порта 22. Современному серверу практически не нужна ни одна служба из диапазонов 1-19, а также различные telnet, rsh, gopher, finger... Возьмем gopher для примера и назначим его порт 70 нашему SSH. Все настройки SSH сервиса можно посмотреть и настроить в файле /etc/ssh/sshd_config . Запускаем редактор и меняем порт SSH:  Port 70
   
3. Находим уже упоминавшуюся настройку, разрешающую вход суперпользователю по SSH, и меняем ее на запрет:  PermitRootLogin no
   
4. Также можно указать список пользователей, которым возможен доступ по SSH (и никому другому):  AllowUsers vasya1 katya2
   
5. После модификаций перезапускаем SSH сервер и проверяем настройки доступа:
   
   
6. Попробуем зайти зарегистрированным пользователем старым способом, затем - по новому порту при помощи ключа -p :
   
   
7. Проверим, что администратор потерял последнюю возможность зайти без маскировки другим пользователем:
   
   

7.2 Файервол.

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

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

• мы разрешаем исходящие соединения
• входящие пакеты данных, если они являются ответами на исходящие запросы
• входящие пакеты данных для конкретных служб, в нашем случае - для SSH
• все остальное запрещено

Создадим новый файл с правилами фильтрации /usr/local/etc/firewall, содержание которого приведено ниже:

Программа iptables настраивает cетевой фильтр для Linux. Что конкретно делает данный скрипт? Прежде всего удаляются старые настройки (1), разрешаются входящие пакеты, являющиеся ответом на исходящие соединения (2), разрешаются входящие соединения на порт 70 SSH службы (3), разрешается ping (4), после того, как будут настроены почтовый сервер на работу из вне и сервер установки точного времени, можно будет раскомментировать (5) и (6), загружаются драйверы сетевого фильтра, отвечающие за его корректную работу (7), регистрируются попытки пройти сквозь фильтр (8), отсеиваются все остальные пакеты и соединения (9). Наиболее часто встречающиеся параметры программы iptables:

• -j Действие (принять, отказать)
• -A Фильтр (обычно на вход)
• -i Интерфейс (! имя означает все кроме указанного)
• -p протокол
• --dport порт - порт для принимающей стороны

Изучение iptables может занять довольно много времени, и существует несколько объемных книг по работе с данным фильтром. Мы же на этом остановимся и перейдем к тому, как запускать фильтр при старте сервера. Автозапуск настроим при помощи стандартного скрипта в директории /etc/init.d . Ниже приведено содержание файла управления сетевым фильтром /etc/init.d/firewall :

Данный стартовый скрипт имеет несколько аргументов:

• start и restart устанавливают правила, которые мы обсудили выше
• stop, flush удаляют правила, файервол становится неактивным
• status показывает установленные правила
• panic создает фильтр, который разрешает только SSH cоединения

Чтобы активировать стартовый скрипт, добавим его в системные уровни запуска 2, 3, 4 и 5:

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

7.3 Полуавтоматические обновления.

Чтобы не стать жертвой очередной дыры, найденной в программном обеспечении, необходимо регулярное обновление последнего. Полностью автоматические обновления не всегда хороши, так как они могут бесконтрольно изменить систему и привести ее в нерабочее состояние. Поэтому здесь мы рассмотрим, как настроить полуавтоматическое обновление операционной системы: Linux сам будет проверять наличие заплаток и новых версий, скачивать их, а мы, получив по почте уведомление, вручную проведем обновление под пристальным взором. Обычно ручное обновление происходит в Debian Linux при помощи связки из двух команд apt-get: "apt-get update && apt-get upgrade" или, что даже лучше, "apt-get update && apt-get dist-upgrade".

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

   apt-get update && apt-get install mailx postfix

   
   
2. После загрузки необходимых пакетов происходит их базовая конфигурация. Нам предлагается выбрать режим работы почтовой службы. Это может быть Интернет сайт - посылка и прием электронной почты напрямую нашим сервером, смартхост - посылка происходит через почтовый сервер-посредник, а прием - напрямую, спутник - вся почта обрабатывается другим сервером, локальная почта - прием и передача только внутри сервера:
   
3. Остановимся пока на последнем, локальном варианте. В следующих статьях мы рассмотрим, как настроить почтовую службу на работу с любыми электронными адресами, не только внутренними. Далее нам предлагается выбрать домен, для которого будет обрабатываться почта. У нас пока нет зарегистрированного доменного имени, поэтому оставляем значение по умолчанию:
   
4. Многие могут сказать, что проще было бы вручную зайти на сервер и сразу провести обновление вместо получения локальных сообщений.. Все верно, но мы делаем это на будущее, когда нотификации будут посылаться на внешний почтовый адрес. Кстати, давайте переопределим почтовый адрес администратора так, чтобы системные сообщения получал обычный пользователь и не было надобности заходить на сервер как администратор. Это потом позволит нам слать сообщения сервера на внешний адрес типа Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript . Данное переопределение можно сделать с помощью файла /etc/aliases в виде строк "старый получатель : новый получатель". Добавим tester как нового получателя почты для суперпользователя root и обновим базу псевдонимов почтовой службы:
   
5. Убедимся, что сообщения для администратора будут приходить к пользователю tester:
   
6. Проверим, что почтовый сервер, принимающий почтовые соединения по порту 25, не доступен снаружи. Это можно сделать с помощью "netstat -anptu" , а также c помощью telnet, если последний у Вас установлен:
   
7. Теперь устанавливаем пакет cron-apt, который будет следить за наличием обновлений, скачивать их и уведомлять администратора по электронной почте:
   

   apt-get install cron-apt

   
   
8. cron-apt по умолчанию проверяет обновления раз в сутки. Если Вы хотите настроить время и периодичность, это можно сделать в файле /etc/cron.d/cron-apt . Остается только решить, в каких случаях получать почтовые уведомления - всегда или только, когда есть что обновить. Это можно установить в файле /etc/cron-apt/config:
   
9. После получения письма о том, что обновления загружены на сервер, остается только произвести обновление до конца:
   

   apt-get dist-upgrade

   
   

Настройкой служб безопасности в Linux можно заниматься бесконечно, к тому же существует масса литературы и онлайн-ресурсов по данному вопросу. Для истинных "параноиков" мы бы посоветовали просто сменить операционную систему на OpenBSD - возможно в скором будущем в Rackspace Cloud можно будет установить любую систему, как, например, в "облаке" Amazon.

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