Базовая безопасность в Linux
Вопрос безопасности всегда актуален. Рассмотрим основы защиты сервера под управлением ОС Linux.
Системные обновления
Своевременно устанавливать обновления для ОС - хорошая привычка. Разумеется, бывают случаи, когда обновление влечет за собой негативные последствия, но это происходит крайне редко. Данный процесс можно упростить, если использовать автообновления системы.
В разных дистрибутивах это делается по-своему:
Debian/Ubuntu используют пакет unattended upgrades для автоматических обновлений
CentOS использует yum-cron
В дистрибутиве Fedora используется dnf-automatic
Если сервер под критической нагрузкой, то следует использовать штатные средства.
Ubuntu/Debian:
Fedora/Centos:
Важно! Обновление коснется только тех пакетов и приложений которые не были установлены путем компилирования и получены как исполняемые файлы.
Системные пользователи с ограниченными правами.
Подключение к серверу под учетной записью суперпользователя root небезопасно. Кроме того, мы рекомендуем сменить любого non-root пользователя присутствующего в системе по умолчанию. Да, хотя бы даже пароль.
Изменение пароля происходит командой:
Команду изменит пароль для того пользователя, от которого запускается. Если нужно изменить пароль для другого пользователя, следует выполнять команду следующим образом.
Для Ubuntu/Debian:
Если у вас только пользователь root, то обосновано будет создать пользователя с ограниченными правами.
Для создания пользователя используют команду:
В ходе своей работы программа запросит пароль для учетной записи, сведения о пользователе, которые можно пропустить нажаитем Enter.
По окончании заполнения данных программа запросит подтверждение корректности информации.
Наделяем пользователя правами администратора. Для этого добавим пользователя в группу sudo:
В случае с CentOS/Fedora пользователь создается иначе:
Добавляем пользователя в группу wheel:
Безопасное соединение по SSH
По умолчанию, доступ к серверу Linux осуществляется по паре логин-пароль на 22 TCP-порт. Согласно последним стандартам безопасности, рекомендуется поменять адрес порта сервера, а подключение производить по паре логин-ключ.
Важно! Данный пример подходит для Linux и MacOS.
В начале проверяем генерировались ли ранее ключи для данной учетной записи:
Если результат будет не пустым, то следует пропустить шаг создания ключа. У нас пусто - создаем командой:
В ходе выполнения программы, может быть запрошена парольная фраза и ее подтверждение. Своего рода защита ключа паролем.
Для генерации ключа в Windows подходит программа PuTTY-Gen, которую можно скачать с официального сайта.
После запуска программы, выбираем тип ключа RSA и кликаем по кнопке Generate.
Активно двигаем мышью в поле окна. По окончании процедуры получим следующее:
Копируем публичный ключ и сохраняем приватный в файл.
Добавляем ключ на удаленный сервер.
Linux:
Для MacOS в 2 этапа:
Для Windows:
Существует два варианта решения проблемы.
1 вариант. Залить публичный ключ, который записан в файл с именем authorized_keys с помощью программы WinSCP по пути /home/remoteuser/
Для этого необходимо после запуска программы WinSCP заполнить соответсвующие поля Address, Login и Password.
2 вариант. Подключить к серверу с помощью утилиты putty, выполнить в терминале команду:
Пустой файл authorized_keys будет открыт на редактирование. Вставляем сгенерированный ранее публичный(!) ключ. Он представляет собой одну строку.
Сохраняем файл и выполняем команду:
Настройка службы SSH
Запрещаем авторизацию от пользователя root. Ваша учетная запись должна быть в группе sudo или wheel (в зависимости от ОС) для того чтобы выполнять команды от суперпользователя, как это сделать указано выше. Для непосредственного выполнения команд следует перед командой использовать служебную команду sudo.
Например:
Также для перехода в режим суперпользователя можно использовать одну из двух команд:
либо
Во всех случаях система запросит пароль.
Теперь отключим авторизацию под пользователем root.
Открываем на редактирование файл sshd_config. В Debian/Ubuntu это выглядит так:
Находим строчку:
PermitRootLogin и заменяем его значение на no.
Запрещаем аутентификацию по паролю. Важно это сделать, если у вас уже успешно выполняется подключение по ключу.
Открываем все тот же файл sshd_config.
Находим строку:
Заменяем значение “yes” на “no”.
Строка может быть закомментирована (т.е. перед ней стоит символ “#”), в этом случае ее надо раскомментировать.
Важно! Вы можете оставить авторизацию как по паролю, так и по ключу.
По окончании настроек любого из пунктов, перезапускаем сервер.
Либо
Либо
Защита SSH-соединений с помощью Fail2Ban
Fail2Ban - приложение, которое позволяет блокировать SSH-подключения с определенного IP-адреса по достижении лимита. Разумно полагать, что если пользователь знает пароль к серверу, но ошибается при вводе, то достаточно будет 3-5 попыток. В случае с авторизацией по ключу - достаточно 1-2 попыток. В противном случае это брутфорс.
Fail2Ban способна осуществлять мониторинг и других протоколов, таких как HTTP, HTTPS, FTP и прочие. Используя настройки по умолчанию, осуществляется только мониторинг SSH.
Подробнее о настройке Fail2Ban можно посмотреть по ссылке.
Настройка Firewall
Хорошей привычкой является использование файрволла. Это главный инструмент безопасности любого сервера и/или сети находящейся за ним. Фильтрация трафика позволяет избежать различного рода вторжения. Мы рекомендуем предоставлять доступ только к тем TCP/UDP-портам, которые на самом деле необходимы. По критичным портам либо закрывать доступ к ним, либо ограничивать доступ к ним - только с определенных IP-адресов.
IPTables — утилита командной строки, стандартный интерфейс управления работой межсетевого экрана netfilter в Linux. Для использования IPTables требуются права суперпользователя. Существуют и альтернативные решения UFW и ShoreWall для Debian/Ubuntu и FirewallD для CentOS и Fedora.
Мы же рассмотрим настройку непосредственно IPTables.
Для просмотра действующих правил фильтрации используют следующие команды.
IPv4:
IPv6:
Стандартный вывод выглядит так:
Это означает, что в режиме работы по умолчанию разрешен весь входящий, исходящий и пересылаемый трафик.
Настройка межсетевого экрана и политика его работы зависит от работы ваших сервисов, а также сервисов локальной сети (частный случай проброс порта для RDP). Прежде чем их применять проверьте совпадают ли наши примеры с вашими задачами.
Для IPv4 (файл /tmp/v4):
Для IPv6 (/tmp/v6):
Применение приведенных выше правил.
Для Arch Linux:
1. Создаем файлы /etc/iptables/iptables.rules и /etc/iptables/ip6tables.rules . Вставляем правила из примеров выше (/tmp/v4 и /tmp/v6) в созданные файлы соответственно.
2. Импортируем эти правила для применения iptables:
3. В Arch Linux, по умолчанию, iptables на запущен. Запускаем:
4. Для автоматического запуска iptables, воспользуйтесь материалом по конфигурированию pre-network.conf с ArchWiki.
Межсетевой экран будет запускаться до подключения сервера к сети.
Для CentOS / Fedora:
В данных дистрибутивах, применяемые правила хранятся в файлах /etc/sysconfig/iptables и /etc/sysconfig/ip6tables.
Для управления правилами межсетевого экрана предлагается использование FirewallD, вместо непосредственного администрирования iptables.
Как и в случае с Arch Linux, создаем файлы /tmp/v4 и /tmp/v6. Вставляем в них приведенный выше пример, либо адаптированный вами под свои нужды.
Импортируем правила:
Сохраняем параметры:
Для Debian/Ubuntu:
В дистрибутивах Debian и Ubuntu правила можно писать как вручную, так и использовать утилиту UFW. Рассмотрим ручной вариант.
1. Создаем файлы /tmp/v4 и /tmp/v6. Вставляем в них приведенный выше пример, либо адаптированный вами под свои нужды.
2. Импортируем правила из файлов:
3. Для автоматизации и упрощения загрузки правил iptables при запуске сервера можно использовать пакет iptables-persistent. Устанавливаем из репозитория.
Проверим правила iptables:
Для проверки выполним последовательно команды:
Результат будет примерно таким:
Перезапускаем сервер:
После перезапуска, проверяем правила. Правила должны присутствовать в том же количестве.
Добавление, изменение и удаление правил iptables
Логика работы iptables такова, что правила работают последовательно от первого к последнему. По этой причине невозможно добавить правила привычными командами:
Для добавления правил в этом случае используется:
Важно! Добавляемые правила должны располагаться в определенной последовательности с учетом других правил в цепочке. Для отображения нумерованного списка существует команда:
Например, необходимо добавить новое разрешающее правило для соединений на порт 8080, к существующим ранее из нашего примера выше. Выполняем команду:
Замена правил.
Замена правил выполняется ключом “-R”:
Например:
Удаление правил
Как пример, удалим правило, которое мы добавили ранее:
Т.е. будет удалено правило, в котором мы разрешали подключение к 8080 порту.
Важно! Применяемые правила не применяются автоматически. Для этого необходимо выполнить действия применимые только для вашего дистрибутива, которые мы рассматривали выше.
Базы данных
Не менее важным является защита данных находящихся в некой СУБД. Рассмотрим на примере MariaDB.
После успешной установки необходимо выполнить одну команду:
После чего, программа задаст несколько вопросов касаемых безопасности.
Change the root password? [Y/n] |
Изменить пароль пользователя root? |
Remove anonymous users? [Y/n] |
Удалить анонимных пользователей? |
Disallow root login remotely? [Y/n] |
Запретить удаленное подключение от имени root? |
Remove test database and access to it? [Y/n] |
Удалить базу данных test и доступ к ней? |
Reload privilege tables now? [Y/n] |
Перезагрузить таблицу привилегий сейчас? |
Результат будет примерно таким:
Также не рекомендуется выполнять соединения от имени пользователя root. Лучше создать одного пользователя и с ограниченными правами. Для сайта будет достаточно следующих прав для выполнения запросов вида:
SELECT - выборка из базы
UPDATE - Обновление записей
INSERT - добавление новых записей.
DELETE - удаление записей (иногда, но лучше не использовать).
Не рекомендуется наделять правами:
ALTER - изменение структуры таблиц
DROP - удаление баз данных и таблиц базы
Вполне разумным является и то, чтобы один пользователь был для одной базы данных.
Общие требования к учетным данным
Для защиты сервера и баз данных следует, даже если вы не используете авторизацию по ключу, логичным будет использовать грамотно созданные имя пользователя и пароль.
Так как подбор имен и паролей (брутфорс) происходит по словарю, логично было бы использовать такое имя пользователя, которое с наименьшей вероятностью окажется в словаре. Например, xd11rn и подобные. Не стоит использовать слишком короткие имена пользователей. Главное, потом не забыть имя пользователя.
К паролям есть ряд общих требований:
- не использовать пароли короче 10 символов;
- использовать буквы верхнего и нижнего регистра, а также цифры;
- использовать специальные символы, но только там, где это возможно.