Содержание
Я продолжаю тему защиты своих сайтов от посягательства извне. Рассмотрим внимательно одну проблемку, а точнее неблагоприятное стечение обстоятельств.
Плагины автоматического резервного копирования
Что это такое? Ну просто модуль, который делает резервные копии сайта и базы данных, чтобы их потом можно было восстановить в случае сбоя. В общем случае этот механизм работает так:
по команде или по планировщику запускается скрипт, который архивирует ДатаБазу и файло в определенный каталог. Как правило это wp-content/uploads/ в WordPress, чтобы пользователь смог вытащить архив извне какой-нибудь качалкой (или тем же wget-ом по планировщику!). Всё вроде бы неплохо, налицо имеем повышение отказоустойчивости, выражаемое в резервной копии ресурса.
Идём дальше.
Неправильная настройка robots.txt
Зачастую, я встречал либо слабую, либо вообще полное отсутствие настройки этого файла, знакомого многим веб-разработчикам. Для чего этот файл?
Файл robots.txt содержит указания для поискового робота касательно того, индексировать или нет определенные страницы сайта.
Итак, например:
User-agent: Yandex
Disallow: /cgi-bin
Disallow: /wp-admin
запретят индексировать роботу Yandex-а содержимое каталогов /cgi-bin и /wp-admin, содержащий административные скрипты WordPress. Чтож, вполне неплохо. Вроде всё понятно. Обычно, кстати, запрещают индексировать именно движки сайтов, карты сайта или дублирующий контент (комменты, календарь, облако тегов и т.д.), чтобы улучшить продвижение сайтов (SEO).
Фишка в том, что каталог wp-content/uploads тоже, как правило, не запрещают. То есть поисковики шмонают все закачанные файлы налево и направо… А что если… Вы уже понимаете, к чему я клоню?
Резервные копии прекрасно индексируются
Найти их можно через гугл, достаточно указать лишь фрагмент URL “inurl:/wp-content/uploads” и тип файла – дамп базы данных “filetype:sql”.
Дальше видно всех:

Почти 16000 найденых вложений. И их количество постоянно пополняется.
Открыв любой дамп мы увидим содержимое резервной копии. Никакого SQL-Injection не надо. Всё на ладони.

Да, пароли хранятся в виде хеша (говорил об этом в предыдущей статье), но хеш тоже можно расколоть. Ещё, кстати, может статься так, что в том же каталоге окажется архив с сайтом, где можно найти wp-config.php, содержащий соль, с помощью которой создан хеш. А так же пароль доступа к базе данных.
Забавно, но некоторые сервера отдают и файлы *.inc (для инклудинга в скрипты).
“mysql_connect filetype:inc” запрос выдаст те фрагменты, где есть подключение к БД. Кстати, там весьма часто попадаются логин и пароль для коннекта. И не везде localhost.
Как-то раз при помощи Google я вообще напал на открытый PMA c 43 базами данных:

Оказалось – крупное государственное министерство транспорта (не Россия, слава богу). На ломаном английском кое-как попытался объяснить им о проблеме. Посмотрим, что из этого получится.

Как избежать подобных ошибок на своём сервере
- Внимательно исследуйте все возможности скриптов, что-то автоматически сливающих (базы данных, файлы и т.д.), лучше, если целевой каталог будет недоступен со всех IP адресов. Можно настроить копирование бэкапов на свой сервер по ssh каналу, с авторизацией по ключам. Это будет лучше.
- Пропишите в файле robots.txt запрет на все каталоги, содержащие информацию, не предназначенную для широкого круга лиц.
- Обязательно используйте возможности веб-сервера для ограничения доступа в административные каталоги (.htaccess или acl).
- Не используйте PHPMYADMIN без пароля!
Проверил только что. Всё работает! О_О
А куда оно денется ) Даже если учесть, что администраторы резко починят свои сервера (вы сами-то верите в это?
пройдёт немало времени, прежде чем данные уйдут из индекса.