Проблемы безопасности хостинга

С чем борется хостинг-провайдер

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

DDoS. Поток запросов или пакетов, который исчерпывает канал, файрвол или веб-сервер. Атаки по объёму измеряют в гигабитах, атаки на приложения — в запросах в секунду, и обе целятся в недоступность службы, а не в чтение её данных. Защита живёт на краю сети, до того как трафик дойдёт до клиента.

Злоупотребления клиентов. Спам со взломанного ящика, страница фишинга на бесплатном поддомене, вредоносное ПО для скачивания, сервис стресс-тестов или прокси. Провайдер обязан это найти, приостановить и сохранить доказательства, иначе теряет репутацию весь его диапазон адресов.

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

Подбор учётных данных на панелях. Списки пар вида почта-пароль из других утечек заново проверяют на странице входа. Это работает, потому что люди повторяют пароли, и поэтому панели нужны двухфакторная аутентификация и ограничение попыток по адресу.

Разрушение изоляции между клиентами. Ошибка в ядре, неверно настроенный пул или общая временная папка могут дать одному клиенту прочитать файлы другого. Провайдеры быстро закрывают дыры в ядрах и намеренно разделяют службы; клиенту всё равно не стоит держать секреты в папке, доступной на чтение всем.

Уязвимости панелей и гипервизоров. Панель управления работает от root, а гипервизор запускает каждую виртуальную машину. Ошибка в любом из них — ошибка во всём, что выше. Поэтому панели обновляют по собственному графику, а провайдер осторожен со сторонним ПО на хосте.

Цепочка поставок. Взломанное обновление, вредоносный пакет, зависимость с закладкой. Провайдер наследует доверие, которое вы оказываете каждой установленной им библиотеке, и вы тоже.

Вымогательское ПО. Не только на офисных компьютерах: зашифрованный сервер резервных копий или том хранилища хостинга можно взять в заложники. Ответ — офлайн-копии и копии, защищённые от изменения, и для провайдера, и для вас.

Свои сотрудники. Работник с доступом к биллингу, гипервизору или хранилищу копий может сделать то, чего не может внешний атакующий. Журналирование, разделение обязанностей и проверка сотрудников — сторона провайдера в этой проблеме.

Фальшивые регистрации и мошенничество с оплатой. Украденные карты покупают серверы, которые используют для спама и атак ещё до того, как придёт возврат платежа. Провайдеры проверяют новые аккаунты и ограничивают, что может делать свежий аккаунт.

Майнинг криптовалют. Взломанный сервер или бесплатный пробный аккаунт майнит монеты за счёт провайдера. Признаки — загруженный процессор, горячий корпус и счёт за электричество, которого никто не ждал.

Открытые резолверы и усиление. DNS-сервер или почтовый сервер, который отвечает всем, можно использовать, чтобы умножать трафик атаки. Открытый резолвер — оружие, направленное на кого-то другого, с вашим адресом на нём.

Репутация IP и блок-листы. Когда один адрес в диапазоне шлёт спам, весь диапазон попадает в блок-лист, и каждая почта клиентов теряется. Репутация — общее имущество, и на её восстановление уходят недели.

Перехват: имена, маршруты и аккаунты

Трём атакам вообще не нужна ошибка в вашем коде. Они забирают адрес, а не сервер.

• Перехват BGP. Сеть объявляет маршруты к адресам, которыми не владеет, и трафик к ним уходит не туда. Защита — на стороне провайдера и регионального интернет-реестра: фильтрация маршрутов и RPKI. С сервера это не исправить, но можно заметить, что посетители вдруг приходят ниоткуда.
• Перехват DNS. Кто-то меняет записи вашего домена или отравляет кэш резолвера, и имя указывает на другой сервер. Защита — заблокированный аккаунт регистратора, двухфакторная аутентификация, DNSSEC и наблюдение за опубликованными записями.
• Перехват домена через аккаунт регистратора. Самый частый из трёх. Повторно использованного пароля, письма с фишингом, похожего на регистратора, или захваченного ящика достаточно, чтобы увести домен. Блокировка домена замедляет вора; двухфакторная аутентификация у регистратора и на ящике останавливает кражу.

Урок для владельца сайта короткий: ваш домен ценнее сервера, потому что сервер можно пересобрать, а потерянное имя — нет. Защищайте аккаунт регистратора так же тщательно, как пароль root, и раз в месяц проверяйте запись WHOIS.

Угрозы, с которыми встречается владелец сервера

VPS с публичным адресом сканируют через минуты после включения. Автоматические боты пробуют порт SSH, обычные веб-пути, порты баз данных и утёкшие учётные данные весь день, без человека за монитором. Список ниже упорядочен по тому, как часто небольшой сервер встречает каждую из этих угроз, и в каждой строке назван урок, который её закрывает.

Порядок — не закон, но это честная ставка. Строки с 1 по 3 дают большинство настоящих взломов на небольших серверах, и все три закрываются за один вечер. Строки с 4 по 6 — ошибки настройки, а не атаки, и их ловит чек-лист. Строка 7 — единственная, которая требует работы в самом приложении.

Базы данных и панели в интернете

Базу данных, которая слушает 0.0.0.0:3306, находят сканированием за часы, а страницу входа phpMyAdmin — так же быстро. Ошибка почти всегда одна и та же: в руководстве велели открыть порт для удалённого подключения, и потом его никто не закрыл. Проверьте, что на самом деле слушает, и закройте то, что не нужно:

sudo ss -tlnp

LISTEN 0 151 127.0.0.1:3306 0.0.0.0:* users:(("mariadbd",pid=944,fd=21)) LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6)) LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=812,fd=7)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=701,fd=3))

Здесь в интернет смотрят только Nginx и SSH, и именно этого нужно добиться. Если MariaDB показывает 0.0.0.0:3306, задайте bind-address = 127.0.0.1 в настройке сервера и перезапустите его. Если панель доступна со всех адресов, закройте её правилом файрвола, VPN или хотя бы входом по двум факторам и обновляйте так же часто, как ядро.

Открытые файлы и веб-оболочки

Веб-корень публичен по определению. Всё, что внутри него, можно скачать, если сервер не откажет: папку .git со всей историей кода, файл .env с паролями баз данных и ключами API, backup.sql за прошлый месяц, временный файл редактора с куском настройки. Проверьте через curl, снаружи, так, как это сделал бы атакующий:

curl -sI https://example.com/.git/config

HTTP/2 403

403 или 404 — нужный ответ. 200 означает, что файл может прочитать любой в интернете. Держите такие файлы вне веб-корня и добавьте правило, которое запрещает каждый точечный файл:

sudo vi /etc/nginx/sites-available/example.com

location ~ /\.(?!well-known/) { deny all; }

Исключение .well-known остаётся открытым, потому что проверка Let's Encrypt по HTTP кладёт свой файл доказательства в /.well-known/acme-challenge/; простое location ~ /\. заблокировало бы его, и продление сертификата сломалось бы.

Веб-оболочка — следующий шаг после дыры в загрузке: небольшой файл PHP, который позволяет атакующему выполнять команды на сервере. Признаки — файл PHP, которого никто не писал, в папке загрузок, с именем, похожим на картинку. Найти его — часть обычной работы в уроке 8; предотвратить его — значит никогда не доверять типу файла, который называет браузер, и вообще отказываться выполнять PHP в папке загрузок. Это правило должно стоять до блока location ~ \.php$ из урока 5, потому что nginx использует первое подходящее регулярное выражение location, а блок сервера читается сверху вниз:

sudo vi /etc/nginx/sites-available/example.com

server { listen 443 ssl; server_name example.com www.example.com; root /var/www/example.com/html; # the ssl_certificate lines stay as certbot wrote them location ~* ^/uploads/.*\.php$ { deny all; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

Блок использует сокет PHP-FPM по умолчанию, который у сайта уже есть с урока 5. Урок 8 переключает эту строку на сокет собственного пула сайта после того, как этот пул появится.

Злоупотребление почтой и небольшие потоки

Почтовый сервер ценен для атакующего по двум причинам. Открытый релей шлёт спам за любого, кто попросит, а подделанный домен позволяет кому-то отправлять почту, которая выдаёт себя за вас. И то и другое вредит репутации вашего адреса, а репутация — единственное, что нельзя восстановить переустановкой.

Открытый релей — это ошибка настройки Postfix: слишком широкая запись mynetworks или правило permit без аутентификации. Проверьте его снаружи с адресом, который вам не принадлежит; если сервер принимает письмо к доставке, он пересылает. Правильные настройки и проверка — в уроке 9.

Небольшой поток стоит последним, потому что его проще всего пережить. Несколько сотен запросов в секунду к странице, которая выполняет запрос поиска, могут исчерпать VPS с 2 ГБ памяти; тот же трафик к закэшированной статической странице — ничто. Ограничение частоты в Nginx и кэш перед базой данных превращают небольшую атаку в медленный день. Очень крупная атака — проблема провайдера: трафик нужно фильтровать до того, как он дойдёт до вашей машины.

Что делать в первую очередь

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

1. Отключите вход по паролю для SSH и разрешите только ключи.
2. Установите fail2ban и включите файрвол, разрешив только нужные порты.
3. Включите автоматические обновления безопасности.
4. Сделайте базу данных и любую страницу администрирования доступными только с localhost или по правилу файрвола.
5. Сделайте резервную копию, положите её на другую машину и один раз восстановите её в тестовую папку.

Урок 8 превращает этот список в команды, а урок 9 закрывает почтовую часть.

Тест

Автор статьи: Arthur Isaev