Как поисковик может навредить админу (Google Dorks)

dump

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

Плагины автоматического резервного копирования

Что это такое? Ну просто модуль, который делает резервные копии сайта и базы данных, чтобы их потом можно было восстановить в случае сбоя. В общем случае этот механизм работает так:

по команде или по планировщику запускается скрипт, который архивирует ДатаБазу и файло в определенный каталог. Как правило это 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”.

Дальше видно всех:

google
google

Почти 16000 найденых вложений. И их количество постоянно пополняется.

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

dump
dump

Да, пароли хранятся в виде хеша (говорил об этом в предыдущей статье), но хеш тоже можно расколоть. Ещё, кстати, может статься так, что в том же каталоге окажется архив с сайтом, где можно найти wp-config.php, содержащий соль, с помощью которой создан хеш. А так же пароль доступа к базе данных.

Забавно, но некоторые сервера отдают и файлы *.inc (для инклудинга в скрипты).

“mysql_connect filetype:inc” запрос выдаст те фрагменты, где есть подключение к БД. Кстати, там весьма часто попадаются логин и пароль для коннекта. И не везде localhost.

Как-то раз при помощи Google я вообще напал на открытый PMA c 43 базами данных:

pma
pma

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

mail
mail

Как избежать подобных ошибок на своём сервере

  1. Внимательно исследуйте все возможности скриптов, что-то автоматически сливающих (базы данных, файлы и т.д.), лучше, если целевой каталог будет недоступен со всех IP адресов. Можно настроить копирование бэкапов на свой сервер по ssh каналу, с авторизацией по ключам. Это будет лучше.
  2. Пропишите в файле robots.txt запрет на все каталоги, содержащие информацию, не предназначенную для широкого круга лиц.
  3. Обязательно используйте возможности веб-сервера для ограничения доступа в административные каталоги (.htaccess или acl).
  4. Не используйте PHPMYADMIN без пароля!
Интересно? Поделись с другом
Litl-Admin.ru

Comments:

Comments: 2
  1. valentino

    Проверил только что. Всё работает! О_О

    1. litladmin (author)

      А куда оно денется ) Даже если учесть, что администраторы резко починят свои сервера (вы сами-то верите в это? ;) пройдёт немало времени, прежде чем данные уйдут из индекса.

Leave a Reply