Как защитить ИТ-инфраструктуру: 7 базовых советов +10

Информационная безопасность, Системное администрирование, Серверное администрирование, Блог компании 1cloud.ru, Хостинг, Разработка под e-commerce, Учебный процесс в IT, IT-инфраструктура

Рекомендация: подборка платных и бесплатных курсов системных администраторов - https://katalog-kursov.ru/

В новостях все чаще появляется информация об утечках данных, а крупные компании расходуют баснословные суммы на усиление безопасности. Как отмечает консалтинговая организация IDC, к 2020 году мировые траты на IT Security превысят 100 млрд долларов.

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

В этом материале мы рассмотрим несколько базовых советов, снижающих вероятность взлома ИТ-инфраструктуры и компрометации информации. Примеры в посте приведены для Linux-based систем, однако некоторые описываемые практики применимы и для других ОС.


/ Flickr / Cezary Borysiuk / PD

1. Устанавливайте актуальные обновления безопасности


Этот пункт довольно очевиден, и о важности регулярного обновления приложений писалось и раньше, однако, к сожалению, он все равно не теряет актуальности. Достаточно посмотреть на ситуацию с уязвимостью в OpenSSL — Heartbleed (CVE-2014-0160).

Она позволяет злоумышленникам извлечь закрытый ключ сервера и с его помощью расшифровывать передаваемый трафик. На момент публикации информации об ошибке в 2014 году число уязвимых сайтов насчитывало 500 тыс. Тогда же разработчики из Google Бодо Меллер (Bodo Moller) и Адам Лэнгли (Adam Langley) подготовили патч, который устранил уязвимость. Однако обновление установили не все, и, по данным Shodan, Heartbleed до сих пор подвержены почти 200 тыс. веб-сайтов.

Чтобы поддерживать системы в актуальном состоянии, мы рекомендуем настроить автообновление безопасности для ОС. Большинство вендоров предлагают инструмент для автоматической установки патчей. Например, для Debian есть утилита Unattended Upgrades, а для систем на базе Red Hat — AutoUpdates. В CentOS доступен yum-cron, а в Fedora — dnf-automatic.

Проводить обновление можно и с помощью пакетных менеджеров. Например, для Debian:

apt-get update && apt-get upgrade

Автоматическая установка патчей имеет свои недостатки, например, случаются ситуации, когда обновления приводят к падению системы. Поэтому перед установкой апдейтов в продакшн-среде стоит проводить предварительное тестирование ПО в «песочнице».

Разработчики пакетов обновлений стараются делать так, чтобы программные продукты не вносили потенциально опасные изменения в систему, но они не могут протестировать все возможные комбинации приложений и сервисов. Например, недавно выпущенный патч KB4041676 для Windows 10 отправлял компьютеры некоторых пользователей в бесконечный цикл перезагрузок и выдавал «синий экран смерти».

При этом часть систем после апгрейда по-прежнему остается уязвимой к эксплойтам, пока не будут перезагружены все связанные с ними процессы. Например, в 2014 году в OpenSSL обнаружили несколько уязвимостей, позволяющих злоумышленникам проводить DDoS-атаки. В версии Debian 1.0.1e-2+deb7u10 их закрыли, но для того, чтобы они вступили в силу, требовалось перезагрузить все приложения, связанные с OpenSSL. Для поиска программ, которым нужна перезагрузка, сообщество разработало утилиты checkrestart и needs-restarting.

2. Активируйте защитные расширения


В современных системах крутятся десятки демонов и программ, владельцами которых являются разные пользователи. Традиционная модель Unix (DAC — Discretionary Access Control), называемая добровольной, работает с тремя параметрами при назначении прав доступа: пользователь, группа-пользователь и остальные, что усложняет процедуру управления приложениями.

Чтобы дать администраторам больше возможностей по настройке политик безопасности, были разработаны защитные расширения, базирующиеся на модели MAC (Mandatory Access Control), то есть принудительном контроле доступа. Они дополняют классическую модель и дают возможность установить политики безопасности для всех процессов. Например, «приказать» веб-серверу, чтобы он прослушивал заданный порт, или разрешить ему читать файлы только из указанного каталога.

Среди защитных приложений можно выделить SELinux, AppArmor и GrSecurity (есть и другие), каждое из которых обладает своими достоинствами и недостатками. Далее, мы кратко рассмотрим возможности SELinux, поскольку он является наиболее защищенным (это приложение создавалось для использования в правительственных системах) и, как отмечает сисадмин и создатель nixCraft Вивек Гите (Vivek Gite), имеет наиболее мощные механизмы контроля доступа.

В нем предусмотрены три режима работы. Enforcing является режимом по умолчанию, который блокирует действия, нарушающие установленные политики безопасности. Второй режим (Permissive) фиксирует все нарушения в журнале, но не блокирует их. Третье состояние — Disabled — означает, что система отключена.

Узнать, какой режим установлен, можно, прописав следующую команду:

$ /usr/sbin/getenforce

Для включения SELinux введите (для Fedora):

rpm -qa | grep selinux
rpm -q policycoreutils
rpm -qa | grep setroubleshoot # проверка установленных пакетов

Утилита предоставляет несколько моделей управления доступом:

  1. Type Enforcement (TE): основной механизм контроля доступа. Гибкий, но трудоёмкий. Все объекты и субъекты помечаются идентификаторами, которые затем можно использовать для назначения правил и политик.
  2. Role-Based Access Control (RBAC): системам определяются роли, ассоциируемые с одним или несколькими доменными типами. Диаграмму с ними можно найти здесь.
  3. Multi-Level Security (MLS): все объекты системы получают определенный уровень доступа, который ограничивает их возможности. На своем уровне сервисы могут читать и писать информацию, на уровнях выше — только писать, а ниже — только читать. Диаграмма с уровнями безопасности есть по ссылке.

Как пример ситуации, в которой SELinux защитит инфраструктуру, можно привести ошибку конфигурирования. DNS-серверы часто осуществляют так называемую передачу зон, когда они реплицируют данные между собой. Атакующие могут использовать эту процедуру для трансляции серверам ложной информации. При работе с BIND на Fedora, даже если администратор забудет ограничить круг серверов, которым дозволено обмениваться информацией, политика SELinux предотвратит изменение файлов зон при репликации.

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

Иные юзкейсы, в которых защищает SELinux, есть по ссылке. Подробное руководство по настройке SELinux на Debian вы найдете тут, а гайд для Fedora — здесь.

3. Настройте права доступа и установите парольные политики


Этот момент также довольно очевиден, однако не перестает быть актуальным. По данным исследования, проведенного компанией Intermedia в 2015 году среди двух тысяч офисных работников, 93% респондентов признались, что хотя бы раз пренебрегали требованиями информационной безопасности. При этом 67% работников ИТ-индустрии ответили, что делятся логинами и паролями от различных аккаунтов с коллегами.

Слабые и общие пароли повышают вероятность «заражения» инфраструктуры компании, а неправильная настройка прав доступа открывает лазейки к системам организации. Поэтому мы не рекомендуем подключаться к серверу от имени администратора (root). Лучше создать нового пользователя, ограничить ему права и работать через этот аккаунт, а администрирование выполнять с помощью sudo.

Как отмечают резиденты Stack Exchange, такой подход усложняет злоумышленникам жизнь. Хакеры могут использовать ботов, которые отправляют запрос на подключение по SSH (ssh root@$IP), а затем подбирают пароль, используя стандартные комбинации («root» или «password123» — одни из самых популярных) или брутфорс. Если им удается получить доступ через root, то они приобретают «неограниченную власть» над системой.

Но если root не может подключиться по SSH, ботам сперва придется угадать имя пользователя, что затрудняет процедуру взлома.

Чтобы создать нового пользователя в Debian и Ubuntu, введите в консоль следующую команду:

adduser administrator

Поле administrator можно изменить на любое. Далее, прописывается пароль. В Password Depot рекомендуют придумывать пароли длиной 8–10 символов с буквами разного регистра, цифрами и специальными знаками. Джефф Этвуд (Jeff Atwood), автор блога Coding Horror и соучредитель платформ Stack Overflow и Stack Exchange, отмечает, что пароль длиной 10 и более символов снижает вероятность его появления в списке самых популярных на 80%.

Да, про необходимость составления сложных и длинных паролей хорошо известно, однако на практике этому правилу следуют далеко не все. Команда SplashData проанализировала более 5 млн паролей от аккаунтов работников корпораций, «слитых» в 2016 году. Исследователи пришли к выводу, что большинство паролей были совершенно небезопасны. Пароль «123456» стал самым популярным и использовался 4% аккаунтов всего «тестового» набора. Примерно столько же процентов набрал пароль «password».

Также стоит позаботиться о данных для авторизации других пользователей севера. Выявить слабые пароли можно с помощью утилиты John the ripper. Убедиться, что в системе нет «беспарольных» пользователей, поможет команда:

awk -F: '($2 == "") {print}' /etc/shadow

Чтобы сделать создание паролей обязательной процедурой и задать «время устаревания» пароля, измените настройки в файле pam_cracklib.so:

chage -M 60 -m 7 -W 7 UserName

Запретите повторное использование старых паролей в pam_unix.so и установите ограничение на количество попыток входа.

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

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

«Демонизируйте» сервис, чтобы он сразу запускался под нужным пользователем. Для этого есть два способа. Первый — с помощью скриптов ОС (init или systemd) для запуска/остановки приложения и инструмента мониторинга (monit) для его перезапуска в случае падения. Второй подход — использовать систему контроля процессов (supervisord, s6, daemontools), которая будет управлять работой приложения самостоятельно.


/ Flickr / reynermedia / CC

4. Настройте правила и исключения для файрволов


Недавно была обнаружена уязвимость (CVE-2017-15908) в менеджере systemd, позволяющая проводить DDoS-атаки. Когда уязвимая система отправляла DNS-запрос к DNS-серверу, контролируемому хакерами, он возвращал специальный запрос, который вводил systemd в бесконечный цикл, вызывающий загрузку CPU на 100%.

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

В целом, открыв для доступа извне лишь небольшое число сервисов, вы уменьшаете количество «точек контакта» и, как следствие, снижаете вероятность проникновения в систему.

При установке правил файрвола команда Mailgun рекомендует придерживаться этих принципов:

  1. Перед настройкой новых правил удаляйте уже существующие.
  2. По умолчанию для обработки входящего трафика установите параметр DROP (любой трафик, не удовлетворяющий установленным правилам, не будет пропущен). После этого можно понемногу начать «приоткрывать» доступ во внешнюю сеть.
  3. Не стоит полностью ограничивать трафик Internet Control Message Protocol (ICMP). Роутеры и хосты используют его для передачи критической информации о доступности сервисов, размерах пакетов и др. Как отмечают на Stack Exchange, ограничить ICMP можно, но формат этих запретов будет зависеть от инфраструктуры компании.
  4. Если вы не используете IPv6 — ограничьте этот трафик.

Чтобы реализовать все эти рекомендации, в Mailgun написали свой скрипт для настройки — его вы найдете по ссылке.

5. Организуйте безопасное подключение через SSH


Для начала сгенерируйте надежный SSH-ключ. Это можно сделать с помощью ssh-keygen:

ssh-keygen -t rsa -b 4096 -C foo@example.com  

После этого нужно ввести парольную фразу, которая защитит ключ в том случае, если он будет скомпрометирован. Для организации SSH-соединения можно использовать OpenSSH, который имеет достойную стандартную конфигурацию. Подробную информацию о параметрах OpenSSH вы можете найти в руководстве от Mozilla или на wiki-страничке CentOS.

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

Для этого нужно создать новые ключи и загрузить публичный ключ на сервер. С локального компьютера введите:

ssh-copy-id admin@1.1.1.1

Замените admin на имя владельца ключа, а 1.1.1.1 — на IP-адрес вашего сервера. Для проверки соединения нужно выполнить переподключение.

Также можно совсем запретить SSH-подключение по вводу пароля, чтобы все использовали ключи. Тогда значение параметра PasswordAuthentification в файле /etc/ssh/sshd_config должно быть отмечено как no.

В Ubuntu (или Debian) это будет выглядеть так:

nano /etc/ssh/sshd_config

...
PasswordAuthentication no

Отметим, что дополнительную безопасность подключения можно обеспечить с помощью 2FA (двухфакторной аутентификации).

6. Используйте криптографию


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

При выборе инструмента или библиотеки для шифрования, команда Mailgun, а также резиденты Stack Exchange, советуют следовать этим правилам:

  1. Используйте современные симметричные шифры: наиболее популярными вариантами являются AES и Salsa20 (NaCl).
  2. Применяйте MAC (message authentication code) для контроля целостности и аутентификации источника данных. Хорошими вариантами будут HMAC-SHA-512 или Poly1305.
  3. Обратите внимание на качественные рандомайзеры для генерации ключей и временных кодов. Например, /dev/urandom.
  4. Если инструмент работает с парольными фразами, убедитесь, что он использует KDF.

На Stack Exchange в соответствующем треде пользователи приводят множество инструментов для создания систем шифрования (например, entlib или Bouncy Castle). Если очень нужно, можно создать и собственную утилиту, однако резиденты Reddit и Quora говорят, что такой подход лишь повышает риск взлома. Как отмечают на Stack Exchange, чаще всего самодельные шифры редко выдерживают атаки хакерских утилит для взлома полиалфавитных шифров и шифров подстановки.

Дополнительно приведем несколько источников, с которыми можно ознакомиться перед началом работы с криптографическими системами. Первый — это курс Crypto101, который ведет Лоренс ван Хоутвен (Laurens Van Houtven), директор компании Principal, занимающейся подготовкой команд по безопасности для стартапов. Второй ресурс — the matasano crypto challenges — здесь собраны 48 упражнений, демонстрирующих атаки на реальные шифры. Авторы утверждают, что это более эффективный способ изучения криптографических принципов, чем чтение книг по теме.

7. Регулярно создавайте и проверяйте бэкапы


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

Из недавних примеров — удаление части базы данных с запросами на изменение документации и кода проектов пользователей GitLab сисадмином из Нидерландов. Тогда в компании отметили, что ни одна из пяти внедренных систем хранения бэкапов не помогла восстановить информацию.

Поэтому создавать бэкапы и проверять их готовность стоит как можно чаще, естественно, с учетом требований бизнеса. Например, инженеры компании Neon Rain, занимающейся разработкой веб-приложений, создают резервные копии файлов раз в неделю, а бэкапы баз данных — каждую ночь. Ежедневно создают резервные копии баз данных и в Cloud Academies. Что касается проверки бэкапов, то, например, в Chalvington Group, возможность восстановления оценивается каждое утро.

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

Если вы не хотите организовывать собственную бэкап-инфраструктуру, то имеет смысл передать эту задачу стороннему вендору, который возьмет заботы по хранению резервных копий на себя. Например, мы в 1cloud выполняем резервное копирование раз в сутки, а клиент сам выбирает требуемое время хранения копий (7, 14, 21 или 28 дней).

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



Тройка материалов по теме из нашего корпоративного блога 1cloud:




К сожалению, не доступен сервер mySQL