Я не буду рассматривать даже смену стандартного порта SSH, не говоря уже о настройке гейт-сервера. Возможностей и вариантов обезопасить свой сервер масса.
Эта статья о том, как быстро настроить сервер так, чтобы минимизировать риски взлома и получения абузы (abuse) от хостера. Подойдет, если сервер временный или на нем не размещается что-то критически важное.
Если вы – серьезный дядя (или тетя) с бизнесом, то данная статья вам не нужна. Лучше наймите специалиста по информационной безопасности. Серьезно.
Сервер всегда под угрозой
Необходимо понимать, что сервер смотрит в интернет, а интернет – это опасное место.
Сеть постоянно сканируют тысячи вредоносных ботов и заражают любые уязвимые серверы и сайты. Под раздачу попадают абсолютно все. Атака на ваш сервер – это исключительно вопрос времени. Это неминуемо.
Вредоносу все равно, что у вас на сервере или сайте – если есть потенциальная возможность его заразить, это произойдет.
Зараженный сервер может быть использован злоумышленниками для:
- рассылки спама,
- размещения фишинговых страниц,
- спуфинга,
- исходящих атак на другие серверы,
- DDoS,
- в качестве промежуточного узла для маскировки нелегальной деятельности,
- майнинга криптовалюты и еще много чего другого.
Поэтому необходимо хотя бы слегка усложнить задачу ботам и потенциальным злоумышленникам.
Используйте SSH-ключи вместо паролей
По умолчанию при создании VDS для root-пользователя генерируется хороший пароль, но про него лучше сразу забыть, ведь можно добавить SSH-ключ. В отличие от паролей, подобрать SSH-ключи невозможно.
Опишу кратко. Я использую Linux, но вы можете запускать ровно те же команды в WSL или терминале на Mac. Также предполагаю, что на сервере используется ОС Ubuntu.
Создаем ключи
Ключ генерируется на стороне клиента, то есть прямо на вашем домашнем компьютере. Делается это в командной строке вот так:
ssh-keygen
После запуска команды выше надо будет ввести имя ключа (можно просто нажать Enter) и passphrase для дополнительной защиты ключа паролем (опять же можно оставить пустым).
Сгенерируются два файла: id_rsa и id_rsa.pub, это связка SSH-ключей. Они представляют собой обычные текстовые файлы, в которых содержатся хэши.
- id_rsa – приватный ключ. Должен оставаться на вашем компьютере. Ни в коем случае его нельзя никому передавать. Это будет ваш пропуск на сервер.
- id_rsa.pub – открытый (или публичный) ключ. Вот его надо добавить на сервер.
Скопируйте все содержимое файла id_rsa.pub и вставьте в поле «SSH-ключ» при создании сервера.
Если сервер уже создан, то добавить ключ можно с помощью команды (выполняется на вашем компьютере):
ssh-copy-id id_rsa.pub root@0.0.0.0
Вместо 0.0.0.0 подставьте IP сервера. Потребуется ввести текущий пароль root.
После того как сервер с SSH-ключем установился или вы добавили ключ вручную, к серверу можно подключиться уже без ввода пароля с помощью команды (не забываем подставить IP сервера):
ssh root@0.0.0.0
По ходу дела могут возникнуть некоторые сложности (все в статье учесть невозможно), поэтому ошибки гуглим. Любая проблема решаема.
Отключаем пароли
Окей, у нас есть ключ, но подключиться с паролем все еще возможно. Исправим.
Необходимо на сервере отредактировать файл /etc/ssh/sshd_config.
Можно воспользоваться редактором nano:
nano /etc/ssh/sshd_config
Откроется файл, в нем ищем строки:
# To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no
И меняем на:
# To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no
Сохраняем изменения нажатием Ctrl+O и закрываем редактор нажатием Ctrl+X.
Мы запретили доступ по паролям. Чтобы настройки вступили в силу, необходимо перезапустить службу SSH:
systemctl restart ssh.service
Готово!
Закройте порты
Включим файрвол с минимальным изменением стандартных настроек.
Установим сам файрвол:
apt install ufw -y
Обязательно открываем SSH, иначе можем потерять доступ к серверу:
ufw allow ssh
Также я открою порты для работы веб-сервера:
ufw allow http ufw allow https
Теперь включим файрвол:
ufw enable
Вы великолепны.
Порты закрываются для всех входящих соединений, исходящие разрешены. Входящие соединения после выполнения команд выше будут доступны только для портов 22 (SSH), 80 (HTTP) и 443 (HTTPS).
Если надо открыть еще какой-то порт, например 8000, нужно выполнить:
ufw allow 8000
Как итог: залогиниться извне под существующего на сервере пользователя невозможно (приватный ключ есть только у вас), потенциальные дыры в виде торчащих в интернет портов служб закрыты (например MySQL).
Это далеко не самая безопасная конфигурация, но риски снижаются. Сервер все еще можно поломать через уязвимые сайты. Поэтому...
Обновляйтесь!
Это очень важно. Старое ПО – это всегда уязвимое ПО.
Это относится к любым программам, в том числе используемым на сайтах CMS и их плагинам.
С выходом новых версий ПО разработчики закрывают найденные в них уязвимости, поэтому свежая версия программы практически всегда означает, что она самая безопасная.
Если ваш сайт не обновлялся год или больше, то он, скорее всего, уже взломан, и вы об этом можете даже не подозревать. Разумеется «год» – это условный год, взломать могут когда угодно, но если вы обновлялись, то это произойдет с гораздо меньшей вероятностью.
Делайте бэкапы, заклинаю!
Я мог бы написать этот заголовок красным шрифтом с капслоком, но не буду.
Резервная копия – это ваш спасательный круг во многих ситуациях, в том числе при заражении вредоносным кодом. Не нужно лишать себя возможности восстановить данные. Представьте, что завтра ваш сайт пропадет. Что вы будете делать?
Хостеры предлагают автоматические резервные копии, о которых вам не надо заботиться, но я также настоятельно рекомендую делать копии самостоятельно. В интернете масса инструкций о том, как это сделать.
Копия хостера может оказаться для вас слишком старой, и тогда вы можете потерять важные данные. В конце концов, невозможно избежать сбоев, и резервные копии могут быть утрачены. Хранить бэкапы в одном месте – не меньшее зло, чем не делать бэкапы вовсе.
Заключения у данной статьи не будет.
Комментарии