Каждое утро я проверяю почтовые уведомления logwatch и получаю основательное удовольствие, наблюдая несколько сотен (иногда тысяч) безуспешных попыток получить доступ. (Многие довольно прозаичны — попытки авторизоваться как root
с паролем 1234
снова и снова). Приведённая здесь общая методика подходит для серверов Debian/Ubuntu, которые лично мы предпочитаем всем остальным. Они обычно служат только хостами для контейнеров Docker, но принципы те же.
На больших масштабах лучше использовать полностью автоматические установки с инструментами вроде Ansible но иногда вы просто поднимаете единственный сервер — для таких ситуаций предназначена инструкция.
У нас ещё даже нет пароля для рута. Хотелось бы выбрать что-нибудь случайное и сложное. Используем генератор менеджера паролей с настройками максимальной сложности. Менеджер паролей сохраняет пароль и шифрует его, доступ к нему возможен только по длинному мастер-паролю. Здесь предусмотрена пара избыточных мер защиты (длинный, сложный случайный пароль + защита пароля шифрованием и другим длинным паролем). Используете вы парольный менеджер или другие инструменты, сохраняйте пароль в безопасности, применяя какую-нибудь форму шифрования. Вам понадобится только этот рутовый пароль в случае потери пароля sudo.
# passwd
Теперь следует обновить репозитории и накатить последние патчи. Далее будет отдельный раздел по автоматизации установки обновлений безопасности.
apt-get update apt-get upgrade
Вам никогда не следует заходить на сервер как рут. Мы следуем тем же правилам при создании пользователей, которые установил Брайан Кеннеди, но вы можете использовать собственные. У нашей маленькой команды не было проблем с использованием единственного пользователя для авторизации, но в больших командах лучше создать разных пользователей с разными уровнями привилегий, где только избранные получают привилегии sudo.
useradd deploy mkdir /home/deploy mkdir /home/deploy/.ssh chmod 700 /home/deploy/.ssh
Устанавливаем предчтительную оболочку для пользователя deploy, мы используем bash:
usermod -s /bin/bash deploy
Помните: chmod 700
означает, что владелец аккаунта обладает правами на чтение, запись и запуск программ. Мы всё ещё находимся с правами рута, но через минуту мы запустим команду chown
рекурсивно на этой папке для пользователя deploy и группы deploy. Только этот пользователь должен иметь право работать с папкой .ssh.
Мы стараемся не использовать пароли для входа на сервер. Насчёт этого было много споров после того как вышла инструкция Брайана, но я тоже склонен согласиться с такой позицией. Вот несколько замечаний на этот счёт:
Итак, оставим в прошлом аутентификацию по паролю. Скопируйте содержимое id_rsa.pub со своей локальной машины на серверы в файл authorized_keys.
(Убедитесь, что указан именно `.pub`. Это кажется очень простым, но я встречал двух товарищей (оба *не* работают в нашей компании — они бы быстро прекратили здесь работать) за свою карьеру, которые прислали мне свои секретные ключи (`id_rsa` без расширения .pub), когда я попросил прислать открытый ключ. )
vim /home/deploy/.ssh/authorized_keys
Установим правильные привилегии, руководствуясь принципом безопасности Linux, известным как принцип минимальных привилегий:
chmod 400 /home/deploy/.ssh/authorized_keys chown deploy:deploy /home/deploy -R
chmod 400
устанавливает разрешения, так что файл может прочитать только владелец. Другая команда chown
делает пользователя deploy и группу deploy владельцами (рекурсивно) их домашней директории. Мы упоминали об этом ранее, когда устанавливали разрешения на чтение, запись и исполнение для владельца этой директории.
[ad name=»Responbl»]
Вернёмся к этому чуть позже, когда правильно протестируем нашего пользователя deploy и sudo для отключения авторизации рута и установки авторизации только по ключу ssh.
Мы собираемся проверить, как происходит авторизация пользователя deploy, в то же время сохраняя открытым соединение по ssh для рута на всякий случай. Если всё работает нормально, мы используем наше открытое подключение рута, чтобы установить пароль для deploy. Поскольку мы отключаем авторизацию по паролю, то этот пароль будет использован при применении sudo. Снова мы запускаем парольный менеджер для генерации сложного и случайного пароля, сохраняем его в зашифрованном виде и сообщаем коллегам (синхронизация зашифрованного файла с паролем).
passwd deploy
Установка sudo простая. Открываем файл sudo:
visudo
Добавляем группу %sudo
под рутовым пользователем, как показано ниже. Убедитесь, что все остальные пользователи и группы отбиты комментариями с символом #
(у пользователей нет префиксов, а группы начинаются с %
). На большинстве свежих установок там ничего нет, но на всякий случай.
root ALL=(ALL) ALL %sudo ALL=(ALL:ALL) ALL
Теперь добавим пользователя deploy
в группу sudo
.
usermod -a -G sudo deploy
Это предоставит пользователю deploy доступ к sudo после введения пароля, который мы только что создали.
Конфигурация ssh для этой машины хранится здесь:
vim /etc/ssh/sshd_config
Вы захотите добавить туда несколько строк. Мне кажется, они довольно понятны сами по себе. Это IP-адрес, который вы используете для подключения. У нас в компании используется VPN-конфигурация с OpenVPN и криптографической аутентификацией, так что для подключения к серверу нужно также пройти аутентификацию и быть подключённым к VPN.
PermitRootLogin no PasswordAuthentication no AllowUsers deploy@(your-VPN-or-static-IP)
Активируйте все эти правила, перезапустив службы ssh. Вероятно, придётся переподключиться (делайте это через пользователя deploy!).
service ssh restart
Обычно здесь два лагеря. Одни используют IPtables напрямую, а другие применяют удобный интерфейс под названием ufw
, который представляет собой слой над IPtables для упрощения процесса настройки. Более простой вариант обычно предпочтительнее с точки зрения безопасности. ufw действительно неплох и помогает в основных вещах.
ufw
установлен по умолчанию на Ubuntu, а на Debian достаточно запустить команду
apt-get install ufw.
По умолчанию ufw
должен отказывать во всех входящих подключениях и разрешать все исходящие, однако, он не будет запущен (потому что иначе как бы вы подключились?). Мы пройдёмся и явно разрешим соединения, которые считаются нормальными.
Во-первых, следует убедиться в поддержке IPv6. Откройте конфигурационный файл.
vim /etc/default/ufw
Установите IPv6 в значение yes
.
IPV6=yes
Для остальных портов, которые мы собираемся открыть, можно просто использовать инструмент ufw
из командной строки, что очень удобно.
sudo ufw allow from {your-ip} to any port 22 sudo ufw allow 80 sudo ufw allow 443 sudo ufw disable sudo ufw enable
Первое — это избыточная мера, которая гарантирует, что только соединения с нашего IP-адреса могут соединяться по SSH (стандартный порт SSH) Но Мнения расходятся, назначать ли для соединений SSH стандартный или нестандартный порт. См. здесь и здесь аргументы обеих сторон.. Вторая и третья команда открывают трафик http и https.
[ad name=»Responbl»]
Примечание: Спасибо chrisfosterelli за замечание, что если вы собираетесь установить первое правило (а вам следует это сделать), то убедитесь, что у вас статичный IP-адрес или безопасный VPN, к которому вы подключаетесь. Динамический IP-адрес оставит вас без доступа к серверу когда-нибудь в будущем.
Мне они нравятся. Они не идеальны, но это лучше, чем пропустить патчи после их выхода.
apt-get install unattended-upgrades vim /etc/apt/apt.conf.d/10periodic
Обновите этот файл следующим образом:
APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "1"; APT::Periodic::AutocleanInterval "7"; APT::Periodic::Unattended-Upgrade "1";
Я в целом согласен с Брайаном, что лучше отключить обычные обновления, а оставить только обновления безопасности. Идея в том, что будет не очень хорошо, если приложение внезапно перестанет работать из-за обновления какого-то пакета с зависимостями, в то время как обновления безопасности очень редко создают проблемы с зависимостями на уровне приложения.
vim /etc/apt/apt.conf.d/50unattended-upgrades
Отредактируйте файл следующим образом:
Unattended-Upgrade::Allowed-Origins { "Ubuntu lucid-security"; //"Ubuntu lucid-updates"; };
Всё готово.
fail2ban — отличный пакет, который проактивно блокирует подозрительную активность, как только она обнаружена. В их вики сказано, что fail2ban сканирует файлы логов (например, /var/log/apache/error_log
) и банит IP-адреса, которые проявляют подозрительные признаки — слишком много попыток ввода неправильного пароля, поиск эксплоитов и проч… Сразу после установки Fail2Ban оснащён фильтрами для различных сервисов (apache, courier, ssh и др.).
apt-get install fail2ban
Двухфакторная аутентификация обязательна, если мы проектируем систему, которая соответствует нормам безопасности. Теоретически, если вы активируете двухфакторную аутентификацию поверх всех остальных защитных мер, то тогда для получения доступа к серверу (через вскрытие уязвимостей в приложениях), нападающим придётся также иметь:
Это немало барьеров (четыре), которые придётся преодолеть. Даже если они получат рутовый доступ через sudo, им придётся найти пароль deploy, который защищён шифрованием AES (пятый барьер).
Устанавливаем пакет.
apt-get install libpam-google-authenticator
Для установки запускаем команду и следуем инструкциям:
su deploy google-authenticator
Двухфакторная аутентификация устанавливается очень легко и добавляет хороший дополнительный уровень безопасности.
Этот инструмент скорее для удовольствия и мониторинга постфактум. Logwatch отслеживает логи и в соответствии с настройками высылает по почте ежедневную красиво структурированную сводку. Это довольно занимательные данные, и вы удивитесь, как много попыток доступа к серверу происходит каждый день. Я установил его только для того, чтобы продемонстрировать коллегам, насколько важно иметь хорошую безопасность.
[ad name=»Responbl»]
У DigitalOcean есть отличное описание установки и настройки Logwatch, но если мы хотим уложиться в 10 минут, то просто установим его и сделаем задание cron для ежедневного запуска и отправки письма по электронной почте.
apt-get install logwatch
Добавляем задание cron.
vim /etc/cron.daily/00logwatch
Добавьте следующую строку в файл cron:
/usr/sbin/logwatch --output mail --mailto you@example.com --detail high
Ну вот. После завершения всего вышеперечисленного вашей основной заботой и точкой сбоя станет ваше приложение и сервисы. Это совершенно другая область.
Мы пытаемся максимально формализовать и описать наши лучшие практики и процессы, если хотите узнать больше, изучите наш репозиторий. Всё в открытом доступе, и мы продолжаем пополнять его. Мы надеемся что наша инструкция помогла вам вам в вопросах как сделать Linux сервер безопасным.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…