Как создать надежные меры безопасности для защиты ваших серверов

Введение

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

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

Ключи SSH (Secure Shell)

При работе с сервером большую часть времени вы будете проводить в SSH-соединении с вашим сервером в терминальной сессии. Ключи SSH (Secure Shell) обеспечивают более безопасный метод входа на сервер, чем логины, основанные на паролях. Для аутентификации с использованием ключей SSH подготавливаются два ключа доступа. Первый — это секретный (закрытый) ключ, а второй — общий (открытый) ключ.

Сначала необходимо настроить аутентификацию по ключу SSH. Это достигается путем размещения открытого ключа SSH в соответствующем каталоге на сервере. При первом подключении клиента к серверу у вас потребуют подтверждение владения закрытым ключом. Это делается путем генерации случайного значения, которое затем отправляется вашему SSH-клиенту. SSH-клиент, в свою очередь, использует закрытый ключ для шифрования ответа. Этот ответ отправляется на сервер. Затем сервер расшифровывает сообщение от клиента с помощью вашего открытого ключа. Если случайное значение успешно расшифровано сервером, это указывает на то, что у клиента есть закрытый ключ. В этом случае аутентификация подтверждается, и может быть установлено соединение с сервером без пароля.

Повышение безопасности с помощью ключей SSH

Хотя авторизация по паролю или любая аутентификация по SSH полностью зашифрованы, злоумышленники все же могут попытаться получить доступ к серверу. Особенно если им стал известен публичный IP-адрес сервера. Перебирая все возможные комбинации клавиш, современные вычислительные мощности позволяют взламывать пароли, и злоумышленники часто предпринимают такие попытки. Если автоматизировать эти попытки доступа, то путем систематического перебора различных комбинаций можно в конечном итоге подобрать правильный пароль.

Благодаря использованию зашифрованной аутентификации SSH нет необходимости включать пароли для входа в систему. Ключи SSH обычно содержат огромное количество комбинаций, которые злоумышленнику пришлось бы перебрать. Увеличенное количество битов многократно умножает число возможных комбинаций, необходимых для взлома шифрования. Таким образом, перебор всех возможных комбинаций алгоритма ключа SSH занял бы колоссальное количество времени. В результате это предприятие становится не стоящим времени злоумышленника. Вот почему шифрование SSH обычно считается «неподдающимся взлому».

Внедрение ключей SSH

Для входа на любой удаленный Linux-сервер следует использовать ключи SSH. Ключ можно сгенерировать на локальной машине, а открытый ключ передать на сервер за считанные минуты. Из этого руководства вы получите базовое представление о том, как использовать SSH для подключения к удаленному серверу в Ubuntu.  Вы также можете ознакомиться с нашим подробным руководством по настройке аутентификации на основе ключей SSH на сервере Linux.

В целом, запрет пользователю root на прямой вход по SSH является общепринятой передовой практикой, в то время как вход выполняется под непривилегированным пользователем с использованием такого инструмента, как sudo, для повышения привилегий по мере необходимости. Это известно как принцип наименьших привилегий: метод ограничения прав доступа. Как только вход под непривилегированной учетной записью будет проверен по SSH, вход для root можно отключить, установив директиву PermitRootLogin no в файле /etc/ssh/sshd_config на вашем сервере. Затем сервер можно перезапустить с помощью команды процесса SSH sudo systemctl restart sshd.

Брандмауэры

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

По умолчанию на сервере может быть запущено несколько служб, и их можно разделить на следующие группы:

• Внутренние службы: Доступ к ним должен осуществляться только локально с самого сервера. Это предотвращает доступ к службам из общедоступного интернета (например, база данных, доступная только через локальные подключения).
• Публичные службы: Службы, к которым может получить доступ любой желающий, часто анонимно, в интернете. К ним относятся веб-серверы, которые позволяют посетителям получать доступ к вашему сайту.
• Частные службы: Только авторизованные учетные записи из определенного набора мест могут получать доступ к этим службам (например, панель управления базой данных phpMyAdmin).

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

Повышение безопасности с помощью брандмауэра

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

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

Внедрение брандмауэров

Для систем Linux доступно множество брандмауэров. Некоторые из них довольно сложны. Однако типичную настройку брандмауэра обычно требуется выполнять только во время первоначальной настройки сервера или при изменении служб на сервере. Это займет всего несколько минут вашего времени. Ниже приведены некоторые варианты настройки и активации брандмауэра:

• Для CentOS вы можете воспользоваться нашим руководством по настройке брандмауэра с помощью FirewallD на CentOS 7.
• Наше руководство по Iptables поможет вам просмотреть список и удалить правила брандмауэра Iptables.

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

Сети Virtual Private Cloud (VPC)

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

Повышение безопасности с помощью сетей VPC

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

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

Использование аудита для повышения безопасности

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

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

• Должна ли данная конкретная служба быть активно запущена?
• Запущена ли она на оптимальных сетевых интерфейсах?
• Подходит ли эта служба лучше всего для публичного или частного сетевого интерфейса?
• Правильно ли настроены правила брандмауэра для разрешения легитимного трафика к этой службе?
• Блокируется ли нелегитимный трафик моими правилами брандмауэра?
• Включена ли система оповещения об уязвимостях безопасности?

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

Проведение аудита служб

Для аудита запущенных служб используйте команду ss, чтобы вывести список всех портов UDP и TCP, активно используемых на сервере. Вот пример использования команды ss с PID имени программы для проверки прослушиваемых портов TCP и UDP:

Будет возвращено нечто похожее на следующее:

Основное внимание следует уделить столбцам Netid, Local Address:Port и Process:

• Если значение Local Address:Port равно 0.0.0.0, это означает, что служба активно принимает все соединения на всех сетевых интерфейсах IPv4. Если адрес равен [::], то трафик принимают все соединения IPv6.
• В приведенном выше примере и Nginx, и SSH прослушивают все публичные интерфейсы на обоих сетевых стеках (IPv4 и IPv6).

В приведенном выше примере вы можете выбрать, нужно ли разрешить SSH и Nginx прослушивать оба интерфейса или только один из них. Как правило, неиспользуемые службы рекомендуется отключать, чтобы они не запускались. Например, если ваш сайт должен быть доступен только по протоколу IPv4, полезно отключить интерфейсы IPv6, чтобы ограничить риски.

Поддержание актуальности с помощью автоматических обновлений

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

Помимо аудита серверов, автоматические обновления могут значительно снизить подверженность атакам. Они также значительно сократят время, затрачиваемое на обслуживание серверов.

Как активируются автоматические обновления

Автоматические обновления теперь являются дополнительной функцией в большинстве серверных дистрибутивов. В Ubuntu, например, администратор может выполнить следующую команду:

Для получения дополнительной информации о внедрении автоматических обновлений ознакомьтесь с разделом «Автоматические обновления» здесь. Для Fedora инструкции можно найти здесь. Обратите внимание, что автоматические обновления будут устанавливать только то программное обеспечение, которое изначально было установлено через систему управления пакетами вашей системы. Любые дополнительные приложения, например веб-приложения, необходимо будет проверять на наличие обновлений вручную отдельно или настраивать для автоматического обновления индивидуально.

Индексация каталогов

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

Повышение безопасности путем отключения индексации каталогов

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

Отключение индексации каталогов

В большинстве случаев для отключения индексации каталогов достаточно добавить всего одну строку в конфигурацию вашего веб-сервера.

• Выполните следующие шаги для отключения отображения каталогов в Apache Wiki. Убедитесь, что директива Options -Indexes указана в блоках конфигурации Apache Directory.
• В Nginx индексация отключена по умолчанию, поэтому никаких дополнительных действий в этом отношении не требуется.

Регулярное резервное копирование

Хотя резервное копирование не является мерой безопасности, оно крайне важно для защиты данных и всей системы в случае ее компрометации. Оно также помогает проанализировать, как система могла подвергнуться атаке. Рассмотрим неблагоприятный сценарий, когда ваша система атакована программой-вымогателем (вирусом или вредоносным ПО, которое шифрует файлы в вашей системе и расшифровывает их только в том случае, если вы заплатите хакеру деньги). Если резервных копий данных нет, ваш единственный выбор — заплатить деньги, чтобы вернуть доступ к своим данным. Если же резервная копия данных надежно сохранена, вы по-прежнему будете иметь к ним доступ и сможете восстановить данные без необходимости доступа к скомпрометированной системе.

Повышение безопасности за счет регулярного резервного копирования

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

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

Внедрение регулярного резервного копирования

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

Вот еще несколько моментов, которые следует учитывать при разработке плана аварийного восстановления:

• Если вы работаете с динамически меняющимися данными, резервное копирование, скорее всего, должно выполняться чаще. В случае потери данных, если последняя резервная копия была сделана слишком давно, вы можете быть вынуждены вернуться к устаревшим данным.
• Подумайте о самом процессе восстановления из резервной копии. Потребуется ли для этого добавить новый сервер или можно восстановить существующий?
• Каков максимальный период времени, в течение которого сервер может оставаться неработоспособным?
• Является ли резервное копирование на удаленную площадку необходимым решением?

Чтобы узнать больше о решениях CloudSigma для аварийного восстановления, ознакомьтесь с нашей статьей в блоге, где подробно рассказывается, почему наше решение «Аварийное восстановление как услуга» (Disaster-Recovery-as-a-Service) является идеальным дополнением к облаку. А здесь вы можете узнать больше о функциях безопасности & непрерывности бизнеса CloudSigma. Также у нас есть подробное руководство о том, как легко настроить функцию резервного копирования CloudSigma.

Частные сети и VPN

Частная сеть — это сеть, доступ к которой и использование которой разрешены только определенным пользователям или серверам. Безопасное соединение между удаленными устройствами, позволяющее соединению работать так, как если бы оно находилось в частной сети, — это VPN (виртуальная частная сеть). Она предоставляет вам возможность защищать соединения в частной сети и подключать удаленные серверы.

Как частные сети повышают безопасность?

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

По сути, использование VPN — это способ разграничить то, что могут видеть сотрудники вашей организации. Переписка будет полностью безопасной и конфиденциальной. Конфигурации приложений позволят пропускать трафик виртуального интерфейса через VPN. Таким образом, только те службы, которые предназначены для взаимодействия с клиентами через интернет, будут доступны в публичной сети.

Насколько сложно внедрить VPN?

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

Первоначальная настройка VPN немного сложнее. Однако дополнительная безопасность, которую это дает, стоит того для большинства сценариев использования. Конфигурационные данные и общие параметры безопасности необходимо установить и настроить на каждом сервере в сети. Для получения более подробной информации о том, как работает VPN, и обзора настройки OpenVPN на Ubuntu, следуйте этому руководству. Вы также можете воспользоваться этим руководством, которое проведет вас через шаги по подключению сети VPN к инфраструктуре CloudSigma.

Шифрование SSL/TLS и инфраструктура открытых ключей

Создание, управление и проверка сертификатов для идентификации пользователей и шифрования связи называются инфраструктурой открытых ключей (PKI). Различные объекты могут проходить взаимную аутентификацию с использованием SSL или TLS сертификатов. После этого они также могут использоваться для установления зашифрованного соединения.

Как сертификаты повышают безопасность

Для шифрования трафика и проверки подлинности участников на сервере крайне важно создать центр сертификации (CA) и иметь возможность видеть все сертификаты вашей сети. Это может помочь предотвратить атаки типа «человек посередине» (man-in-the-middle), при которых сервер имитируется хакером, а трафик перенаправляется.

Конфигурацию каждого сервера можно настроить так, чтобы он доверял централизованному CA. Любым последующим подписям сертификатов можно будет доверять безоговорочно. Если шифрование SSL/TLS поддерживается протоколами и приложениями, которые использует ваш сервер, вы можете защитить свою систему без накладных расходов на VPN-туннель. Для получения дополнительной информации следуйте нашему руководству по автоматизации продления SSL-сертификатов LetsEncrypt для Nginx.

Сложность внедрения

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

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

Обнаружение вторжений в систему и использование аудита файлов

Аудит файлов — это процесс, используемый для сравнения файлов и их атрибутов в вашей системе в полностью безопасном, исходном состоянии с текущим состоянием вашей системы. Это хороший метод для поиска и изоляции несанкционированных изменений в системе.

Под IDS, intrusion detection system, понимается программное обеспечение для мониторинга, которое отслеживает любую несанкционированную активность в системе. Как правило, оно использует методы аудита файлов для поиска любых непредвиденных изменений в системе.

Повышение безопасности с помощью IDS и аудита файлов

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

Аудит файлов и IDS — единственные надежные процессы, позволяющие убедиться, что система не подверглась непредвиденным изменениям. Большинство злоумышленников хотят использовать взломанные серверы в течение длительного времени, и для этого им необходимо сохранять скрытность своих действий. Они могут заменить исполняемые файлы уязвимыми или скомпрометированными версиями. Любые файлы, измененные в системе, будут обнаружены при аудите файловой системы. Это позволяет вам быстро узнать, была ли нарушена целостность системы.

Уровень сложности внедрения

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

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

Хотя это, безусловно, увеличивает административную нагрузку на вашу систему, это один из единственных надежных способов гарантировать, что ни один из файлов не был изменен без вашего ведома. Одними из самых популярных систем обнаружения вторжений и аудита файлов являются Aide и Tripwire.

Изолированные среды

Любой метод, при котором отдельные компоненты запускаются в собственном выделенном пространстве, называется изолированной средой выполнения.

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

Повышение безопасности с помощью изолированных сред

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

Сложность внедрения

Сложность изоляции ваших приложений зависит от типов контейнеризации, которые вы решили использовать. Docker не считает изоляцию функцией безопасности. Однако, когда ваши компоненты разделены по разным контейнерам, изоляция достигается гораздо проще. Вы можете воспользоваться этим руководством по установке Docker на нашу инфраструктуру.

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

Заключительные мысли

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

Однако безопасность — это не статичный процесс, а динамичный. Ее необходимо поддерживать и регулярно обновлять. К ней следует подходить с менталитетом постоянной осведомленности и неослабевающей бдительности. Всегда задавайтесь вопросом, каковы последствия для безопасности при любых изменениях в системе.  Убедитесь, что операционные среды и конфигурации по умолчанию всегда оптимизируют безопасность и работают с достаточно защищенным программным обеспечением.

Приятной работы!