phpMyAdmin в BitrixVM: ставить или обойтись

В составе BitrixVM phpMyAdmin нет. Это не упущение: веб-интерфейс к базе данных, доступный из интернета, — одна из самых частых точек входа при взломе. Но задача никуда не девается: иногда нужно руками посмотреть таблицу, поправить значение или выгрузить дамп.

Сначала попробуйте обойтись без него

В девяти случаях из десяти веб-интерфейс не нужен — достаточно подключиться к базе с рабочей машины через SSH-туннель. Тогда база остаётся закрытой, а работаете вы в привычном клиенте: DBeaver, TablePlus, MySQL Workbench, любом другом.

# пробрасываем порт базы на свой компьютер
ssh -L 3307:127.0.0.1:3306 bitrix@ваш-сервер

# пока сессия открыта, в клиенте подключаемся к:
# хост 127.0.0.1, порт 3307, логин и пароль — из настроек сайта

Ничего устанавливать на сервер не нужно, ничего не остаётся после работы, и закрыть доступ можно, просто завершив сессию.

Где взять логин и пароль

Реквизиты подключения лежат в настройках сайта: /home/bitrix/www/bitrix/.settings.php, а если сайтов несколько — в /home/bitrix/ext_www/<сайт>/bitrix/.settings.php. Нужный блок — connections, там хост, имя базы, логин и пароль.

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

Проверьте, не торчит ли база наружу

По умолчанию служба базы данных в окружении слушает не только локальный адрес:

ss -lntp | grep 3306

Если в выводе *:3306, значит порт открыт на всех интерфейсах, и единственное, что отделяет базу от интернета, — сетевой экран. Проверьте, что он включён и порт закрыт снаружи. Это стоит сделать до того, как думать про phpMyAdmin.

Если веб-интерфейс всё-таки нужен

Бывает: доступ нужен человеку без SSH, или клиенту на время, или надо показать таблицу на экране. Тогда два правила.

Не кладите его в корень сайта. Папка phpmyadmin в /home/bitrix/www/ становится доступна по адресу сайта — и попадает под те же сканеры, что перебирают wp-login.php и xmlrpc.php. Лучше поднять отдельный сайт в пуле (/home/bitrix/ext_www/) на служебном домене, который нигде не светится.

Закройте доступ на уровне веб-сервера. Минимум — ограничение по адресу и отдельный пароль:

# в конфигурации nginx для служебного сайта
allow 203.0.113.10;   # ваш адрес
deny all;

auth_basic "Служебный доступ";
auth_basic_user_file /home/bitrix/.htpasswd;

И запретите индексацию: служебный адрес не должен появиться в поиске. Подойдёт запрет в robots.txt плюс заголовок X-Robots-Tag: noindex, но главная защита — это не robots, а права доступа. Про разницу мы писали отдельно: robots.txt не удаляет страницы из поиска.

Adminer вместо phpMyAdmin

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

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

Что сделать, когда закончили

1. Удалить файлы интерфейса, а не просто закрыть доступ. Оставленный «на потом» phpMyAdmin — это дверь, про которую все забыли.
2. Удалить дампы, если выгружали: в корне сайта им не место, их отдаёт веб-сервер напрямую.
3. Сменить пароль пользователя базы, если он вводился на стороннем устройстве.
4. Посмотреть журнал веб-сервера: были ли обращения к служебному адресу, кроме ваших.

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

Частые сложности

• Интерфейс не подключается к базе. Проверьте, какой хост указан: в окружении подключение идёт через локальный сокет /var/lib/mysqld/mysqld.sock, а не через сеть. В настройках интерфейса иногда нужно указать именно сокет.
• Страница отдаёт 403. Если файлы положены в папку, где запрещено исполнение PHP, веб-сервер правильно откажет. Это тот самый запрет, который защищает от шеллов, — не снимайте его ради удобства.
• Доступ запрещён для пользователя. Реквизиты из .settings.php дают права только на базу сайта. Для операций вроде создания новой базы нужен административный пользователь, и его пароль хранится отдельно.