Чаще всего проблема между стулом и монитором.
Все, что смотрит в бесконечную даль Интернета, находится в той или иной степени под угрозой атаки вездесущими ботами, хакерами, школьниками и прочими темными сущностями глобальной сети. Это не в последнюю очередь касается мощностей арендных серверов (выделенных или VPS/VDS). Провайдер может обеспечивать базовый функционал защиты от атак на свою инфраструктуру, но то, что юзер творит со своей машиной, провайдера абсолютно не касается. Разве что за доп. плату он может добавить некоторые настройки к VPS, мониторить и фильтровать трафик, поступающий с определенной интенсивностью. Поэтому хочешь не хочешь, а приходится задуматься об обеспечении безопасности своего сервиса вот этими вот маленькими ручками, желательно с минимальными временными и материальными издержками. Под катом рассмотрим несколько простых настроек, которые сведут к минимуму угрозу для вашего VPS, а в конце статьи рассмотрим пару более сложных, но эффективных техник защиты. Примеры команд приведены для ОС Ubuntu.
Всем известно, что мы хороши задним умом, а не передним. Поэтому начнем с очевидных прописных истин.
Политика паролей и ключей
Стандартные пароли
Если театр начинается с вешалки, то VPS сервер начинается с пароля. Провайдер генерирует, как правило, стойкий рандомный пароль с цифрами и буквами разного регистра, по которому вы подключаетесь к VPS. В принципе, сложность такого пароля достаточна, но опыт показывает, что надежные пароли довольно часто меняются на простые, которые не нужно запоминать и долго вводить и которые минимально проходят требования провайдера. К тому же, один и тот же пароль у пользователя может использоваться на нескольких VPS! Не говоря уже, что этот же пароль у него стоит на почту, социальные сети и прочие сервисы.
Новости про сливы баз с паролями мы привыкли пропускать мимо ушей, но следующие 4 совета, пожалуйста, не пропускайте:
меняйте пароль к VPS/VDS как минимум 1 раз в три месяца;
новый пароль должен включать в себя минимум 12 символов и состоять из цифр, букв разного регистра и спецсимволов, разрешенных провайдером. Его можно сгенерировать через утилиту
openssl:
openssl rand <длина пароля> -<система счисления (hex, base64 и пр.)>
или с помощью pwgen:
pwgen <длина пароля> <число паролей>
как вариант используйте менеджеры паролей, например, lastpass, чтобы избавить себя от необходимости каждый раз запоминать новый пароль. А если хочется хардкора, то задумайтесь об токен генераторах OTH (одноразовых) паролей. Мы тут, конечно, не для извращения собрались, но, вдруг, кому-то очень надо :)
а лучше настройте вход по SSH и спите на этот счет спокойно. Об этом далее.
Вход по SSH
Если пароль можно подобрать, то с SSH-ключом такой маневр не пройдет, поэтому этот способ подключения к VPS следует предпочесть вводу пароля. Сам по себе протокол SSH предусматривает шифрование всего трафика, а также допускает выбор алгоритма шифрования, что лишним совсем не будет.
Ключ SSH представляет собой связку публичного и приватного ключа (длиной до 4096 бит). Первый хранится на удаленном сервере, а второй – на компьютере пользователя (очевидно, он не должен быть в публичном доступе). При обнаружении попытки подключения сервер сгенерирует случайную строку и зашифрует ее с помощью открытого ключа. Зашифрованное сообщение можно расшифровать только с помощью соответствующего закрытого ключа.
Сгенерировать SSH-ключ можно следующей командой:
ssh-keygen -t rsa
Вводим имя ключа (можно просто нажать Enter) и passphrase для дополнительной защиты ключа паролем (опять же можно оставить пустым). Будет создано два текстовых файла: id_rsa (приватный ключ) и id_rsa.pub (публичный ключ).
Копируем id_rsa.pub на удаленный сервер:
ssh-copy-id id_rsa.pub root@<IP-адрес сервера>
Потребуется ввести пароль root.
Вуаля, теперь к серверу можно подключиться без ввода пароля с помощью команды:
ssh root@<IP-адрес сервера> -p <номер порта SSH>
По умолчанию номер порта SSH это 22, но об этом будет ниже.
Двухфакторная аутентификации в ЛК хостера и/или панель управления хостингом
Не стоит пренебрегать довольно банальным, но весьма действенным методом как двухфакторная аутентификация в личном кабинете (ЛК) хостинговой компании, а также в панель управления (ISPmanager, например). В таком случае для входа в панель управления помимо стандартных кредов (логина и пароля) сервер потребует ввести временный код, отправленный вам на почту или номера телефона. В таком случае, даже если ваши креды стали известны злоумышленникам, вы можете быть спокойны до тех пор, пока у вас не украдут телефон или почту.
Обновление ПО
Своевременное обновление ПО на сервере – одно из ключевых моментов в обеспечении безопасности VPS. Чаще всего обновления и патчи для ПО выпускаются именно для закрытия ранее обнаруженных брешей и уязвимостей, поэтому наличие актуальных версий программ и обновлений существенно усложнит злоумышленникам задачу взлома.
На Ubuntu это можно сделать ровно в 2 команды. Сначала актуализируем список пакетов:
sudo apt update
Далее обновляем все устаревшие пакеты до последних версий:
sudo apt upgrade
Регулярно обновляйте ПО и тем самым сокращайте риски взлома системы. В то же время, избегайте установки избыточного программного обеспечения, которое в будущем может быть использовано в качестве бэкдора.
Press CTRL S или бэкапы, бэкапы, бэкапы
Как правило, провайдер автоматически делает снимок всего сервера с определенной периодичностью, например, раз в неделю (надо узнавать индивидуально). Однако, по закону подлости все может полететь к чертям в самый неподходящий момент и уж лучше иметь под рукой свежий бэкап системы, чем довольствоваться копией недельной, а то и месячной давности. Здесь у нас есть 2 пути:
Настроить бэкап всей системы или критической ее части (лучше все-таки всей) через панель управления, но в таком случае бэкапы будут занимать дисковое пространство VPS/VDS и вскорости забьют выделенный вам объем. Также можно в качестве места хранения указать любой облачный сервис, но на нем также придется периодически посматривать, осталось ли место для очередного бэкапа. Тем более крайне рекомендуется одновременно хранить бэкапы в нескольких местах. Всякое может случиться и нужно быть к этому готовым.
Воспользоваться услугой автоматического резервного копирования и подключить возможность ежедневного бэкапа на удаленный сервер. В этом случае вам не придется беспокоиться о забитом локальном/облачном диске, этот геморрой полностью ложится на провайдера. НО! Мы настоятельно рекомендуем хранить также копию данных у себя, а не только у хостинговой компании.
Внимание! Оба варианта никто не запрещает комбинировать.
Ставим антивирус
Есть такая байка, что Linux вирусам не подвержен и это совсем не так. Linux по своей природе не защищен от вирусных атак. Но да, чтобы подхватить вредонос, нужно ооооооооочень постараться. Однако, что нам мешает подстраховаться? Сейчас доступно множество антивирусных программ, но на фоне всех остальных заметно выделяется ClamAV. Он используется для обнаружения подозрительной активности и помещения нежелательных файлов в карантин.
Для установки ClamAV выполните команду:
sudo apt-get install clamav clamav-daemon –y
После успешной установки необходимо обновить базу сигнатур. Для этого останавливаем ClamAV:
sudo systemctl stop clamav-freshclam
Вручную обновляем базу сигнатур:
sudo freshclam
Также можно автоматизировать обновление сигнатур, добавив запуск freshclam в планировщик задач cron через crontab, указав также периодичность выполнения (например, раз в час):
crontab -e
59 * * * freshclam
Запускаем сервис (далее обновление базы будет происходить в фоновом режиме):
sudo systemctl start clamav-freshclam
Можно запустить скан всей системы на предмет инфицированных файлов следующей командой:
sudo clamscan --infected --recursive --remove /
infected – выводит название зараженных файлов
remove – удаляет зараженные файлы
recursive – сканирует все субдиректории.
Полезно также установить сhrootkit – специальный сканер, детектирующий разновидность вирусов под названием rootkit, которые способны получить ПОЛНЫЙ контроль над сервером, запускать другие вредоносы, ОТКЛЮЧИТЬ АНТИВИРУС и внести хаос в любую систему. Chrootkit распространяется бесплатно и скорее всего не раз спасет ваш VPS.
Устанавливаем:
sudo apt install -y chkrootkit
Запускаем:
sudo chkrootkit
Альтернативой сhrootkit является rkhunter. Используйте ту утилиту, что придется вам по душе.
Мониторим логи
Мониторинг журналов сервера поможет контролировать то, что происходит с вашим VPS. Файлы системных логов сервера и логов утилит помогут определить нежелательную активность на VPS, подвергается ли сервер кибератакам и наглядно подсветят уязвимые места системы в целом.
Одной из важнейших директорий в системе Linux является /var/log, в которой хранятся журналы, содержащие важную информацию о системе, ядре, менеджерах пакетов и различных приложениях, работающих на сервере.
Пример содержимого папки /var/log:
Нас интересует файл с системной информацией syslog. Для примера посмотрим последние 20 строк:
tail -20 /var/log/syslog
Не работаем в точках общественного питания доступа
Общественные сети никогда не заслуживали общественного опять же доверия. В последнее время распространились подменные сети типа Evil Twin, через которые весь трафик пользователя автоматически попадает к злоумышленнику. Такие сети неискушенному пользователю довольно трудно отличить от верифицированных точек доступа, поэтому не стоит подключаться к своему VPS серверу из таких сетей. Забудьте. Разве что у вас есть надежный VPN, способный обеспечить вашему соединению должный уровень защиты.
Далее идет блок для опытных сталкеров, которые понимают, что и зачем они делают, а также осознают последствия своих действий.
Подменяем порты
Боты – «существа» не очень одаренные умом и выполняют грубо прописанные в них инструкции. Сказано, что ломимся на SSH порт, значит, ломимся на 22 порт, сказано, что ломимся на FTP порт, значит ломимся на 21 порт и так далее. Логично будет запутать бота, поменяв номера ключевых портов, а неиспользуемые порты вообще отключить. Главное действовать последовательно и не обмануть самого себя:
Открываем нужный нам порт через
iptablesилиufw;Меняем старый порт на новый;
Старый порт закрываем.
Важно помнить простое правило: все, что не разрешено - запрещено. Иными словами, открыты только порты для используемых сервисов, все остальные должны быть закрыты.
Кстати говоря, некоторые порты у провайдера, будь то бесплатный VPS или нет, закрыты на уровне роутера, поэтому не лишним будет перед сменой портов уточнить у провайдера, может ли быть открыт нужный вам порт.
Рассмотрим самый распространенный пример – подмену порта SSH. Для этого открываем файл:
/etc/ssh/sshd_config
Находим строку примерно такого содержания:
# What ports, IPs and protocols we listen for
Port 22
Заменяем цифру 22 на любую другую, ПРЕДВАРИТЕЛЬНО ПРОВЕРИВ, ЧТО ЭТОТ ПОРТ НЕ ЗАНЯТ. Опять же говорят, что безопаснее выбрать номер из диапазона 49152-65535. Сохраняем файл и закрываем его. Теперь надо перезапустить сервис (как вариант можно перезагрузить сервер):
sudo systemctl restart sshd
ВНИМАНИЕ! Из вида не стоит упускать два аспекта:
Если вы входите на сервер по SSH, то при каждой авторизации вам нужно будет указывать адрес нового порта.
ssh root@<IP-адрес сервера> -p <НОВЫЙ номер порта SSH>
Бот может быть модифицированным и простым перебором будет стучаться в каждый новый порт, пока не найдет желаемое. Так что смена порта может оказаться бессмысленной.
Теперь о закрытии неиспользуемых портов. Сначала нужно проверить, а какие порты вообще используются. Для того, чтобы определить, какие порты слушаются локально, воспользуемся утилитой netstat. Для портов, доступных извне, применим утилиту nmap.
sudo netstat –ntulp
nmap localhost
Теперь зная, какие порты используются, мы можем закрыть ненужные с помощью утилиты iptables. Пример синтаксиса для закрытия порта:
sudo iptables -A INPUT -p tcp --dport <номер порта> -j DROP
После того, как вы завершите настройку портов, нужно сохранить все созданные правила, чтобы они остались активными даже после перезагрузки. Для этого выполните:
sudo iptables-save
Теперь можно посмотреть активные правила:
sudo iptables -L -n -v
Возможности iptables очень широки и есть огромная куча мануалов, где они описаны более подробно, здесь мы привели лишь базовый ее функционал.
Внимание! Если вы на сервере используете утилиту ufw вместо iptables, то все приведенные выше команды стоит выполнять через ufw. Одновременное использование обеих утилит может привести к коллизии (конфликту) правил. В случае, если у вас одновременно работает и iptables, и ufw, то будет применено последнее созданное правило.
По примеру портов также можно блокировать целые сервисы. Для этого используется утилита update-rc.d. Это для общей образованности, ставить ее необязательно.
Настраиваем Fail2Ban
Программный пакет Fail2Ban рекомендуется, а в некоторых случаях даже необходим для защиты вашего сервера от атак типа «Brute Force» или «Denial of Service». Fail2Ban отслеживает журнал входов, благодаря чему он может заметить те IP-адреса, с которых происходило подозрительно большое количество попыток неудачной авторизации (т.е. происходил подбор пароля), и автоматически создает правило брандмауэра, которое отклоняет все пакеты и блокирует данный IP-адрес, добавляя его в черный список. Блокировка осуществляется путем внесения изменений в правила iptables. Таким образом, благодаря тщательному отслеживанию сетевой активности на основных портах и чтению лог-файлов утилита блокирует ботов и повышает защищенность вашего VPS.
Для установки Fail2Ban вводим следующую команду:
sudo apt install fail2ban
Утилита обладает широким функционалом по настройке правил через конфиг-файлы. Конфиги находятся в каталоге /etc/fail2ban. Прежде, чем что-либо менять, сделайте копию основного конфиг-файла и вносите правки только в него, не притрагиваясь к исходному файлу. Тогда у вас в случае неудачи будет возможность откатиться к исходным настройкам. После изменения конфигурации следует перезапускать Fail2Ban командой:
/etc/init.d/fail2ban restart
Запрещаем вход для root-пользователя
Как известно, root-пользователь обладает неограниченными правами на сервере и большинство атак направлено именно на захват этой учетки. Поэтому имеет смысл отключить возможность заходить на сервер под рутом. Однако, СНАЧАЛА СОЗДАЙТЕ НОВОГО ПОЛЬЗОВАТЕЛЯ С ДОСТАТОЧНЫМИ ПРАВАМИ ДЛЯ УПРАВЛЕНИЯ СЕРВЕРОМ! Извините за капс, просто наболело.
Итак, открываем файл на редактирование:
nano /etc/ssh/sshd_config
Ищем параметр PermitRootLogin и меняем yes на no:
PermitRootLogin=no
Сохраняем изменения и перезапускаем сервис SSH:
service ssh restart
Теперь, когда root-пользователь отключен, для выполнения команд с административными правами перед каждой инструкцией придется вводить незыблемое sudo.
Для тех же, кто привык работать сразу под root-пользователем (осуждаю), не беда. В данном пункте мы лишь запретили подключаться удаленно к этому юзеру по SSH. Можно добавить любого другого пользователя в группу sudo, после чего выполнить команду sudo su и спокойно работать из-под root .
Делаем /boot “read-only” (только для экспертов)
Директория /boot содержит важные для загрузки ядра файлы и по умолчанию права на эту директорию выглядят как “read-write”. Чтобы предотвратить несанкционированное изменение загрузочных файлов, которые имеют решающее значение для бесперебойной работы вашего сервера, рекомендуется изменить уровень доступа на «read only».
Для этого просто отредактируем файл:
/etc/fstab
В конец файла добавляем строку:
LABEL=/boot /boot ext2 defaults, ro 1 2
Сохраняем и закрываем файл. Настройки всегда можно вернуть к прежнему состоянию, просто удалив добавленную строку.
Меняем FTP на SFTP
Протокол FTP прост как три копейки и только ленивый еще не подшутил над его “дырявостью” в плане безопасности, ведь через него файлы передаются напрямую без шифрования. Есть FTPS, но через него шифруются только учетные данные, а никак не сами передаваемые файлы. В результате использования этих двух протоколов вы очень рискуете стать жертвой сниффинга (перехвата трафика) и полностью потерять хранящуюся на FTP информацию.
Чтобы избежать этого, используйте SSH FTP (SFTP). Это безопасное FTP-соединение, поскольку оно полностью шифрует все данные, включая учетные данные и передаваемые файлы. Кроме того, SFTP защищает пользователей от «атак посредника» (man-in-the-middle), поскольку клиент должен пройти аутентификацию на сервере прежде, чем получить доступ к системе.
Для подключения к серверу через SFTP используйте команду:
sftp -oPort=<порт SSH> user@<IP-адрес сервера>
Подключаем мониторинг
Как правило, базовый мониторинг присутствует в любой панели управления VPS. Он показывает стандартные параметры работы системы: загрузка CPU, памяти, диска. Расширенный мониторинг работы VPS/VDS (то есть включая метрики самих сервисов, а не только сервера) - очень классная вещь, если она у тебя есть, то есть когда данная услуга подключена у провайдера по умолчанию или куплена дополнительно. Самостоятельно поднимать мониторинг (отдельный сервер) может оказаться чересчур затратно и реально потребуется в очень ограниченном числе кейсов. Расширенный мониторинг позволяет автоматически создавать тикеты (оповещения) в случае выявления нежелательной активности или роста определенных показателей. В 90% случаев проблема решается еще до того, как пользователь о ней узнал :) Остальные случаи или требуют подтверждения действий владельцем VPS, или требуют действий самого владельца и его технического отдела.
Настраиваем шифрование трафика
Мы отдаем себе отчет в том, что SSL-сертификаты это про веб-сайты, а не про ВПС, однако, а что, собственно, крутится на сервере, если не веб-сервис или сайт? Наша практика показала, что очень часто сайты, работающие на том же Битриксе, очень уязвимы для фишинговых атак. Установка на сервер SSL-сертификата относится к решениям типа “good-practice” в сфере обеспечения безопасности сайтов и онлайн-сервисов. SSL-сертификаты позволяют шифровать поток информации между пользователями вашего сервиса (сайта) и сервером, а также удостоверять подлинность соединения. Примерно каждый VPS/VDS хостинг предлагает услугу по выписке SSL-сертификата на ваш сервис, иногда даже на самом этапе покупки. Он может быть бесплатным (Let’s Encrypt) и платным. Разница состоит в типе сертификата и длительности его действия. Бесплатный действует 90 дней, т.е. каждые три месяца его придется выписывать заново. Коммерческие сертификаты, как правило, выпускаются на один-два, а то и целых три года, что, очевидно, снижает частоту перевыпуска в разы. Также при взломе бесплатного сертификата ответственность лежит только на владельце сервиса, в то время как за взлом платного сертификата вы уже точно будете знать, в кого кидать тапки и даже что-то потяжелее.
Выводы
Как видите, есть очень много способов обезопасить VPS на Linux своими руками и мы очень надеемся, что описанные выше действия вы сможете успешно применять в своих проектах и ваши сервисы станут еще надежнее.
Если же вы чувствуете себя неуверенно в *unix среде или не хотите самостоятельно разбираться в тонкостях всех настроек, тогда ваш вариант это заказать VPS/VDS сервер у надежного хостинг провайдера с профессиональным администрированием 24/7, включенным в специальные тарифы.
Пишите в комментариях, какие другие способы защиты VPS вы знаете? А также свои вопросы/замечания к статье и был ли бы вам интересен подобный материал для VPS на Windows?
Ваш AdminVPS
