Deface - насколько опасно?

опять дубль (пишешь сообщение больше чем 60 секунд - выскакивают два)

Jefa, Очень редкий и малоопытный хакер будет заниматься взломом с использованием своего IP, на 90% уверен что это турецкий прокси. Правильно сделали что исправили права, на большинстве хостингов которые заботятся о безопасности 777 и 666 запрещены. Настоятельно рекомендую конфиги cms закрыть в zend в случае проникновения на хостинг это заставит хакеров пломать голову над паролем для mysql. Также админку cms закройте через .htpasswd ( в DirectAdmin Password Protect Directories) или ручками мануал на русском тут.:)

Правильно, да не все.

Если взлом проводился как тут уже писали через SQL-injection (я имею в виду что попытка взлома была, но вот как конкретно удалось взломать - вопрос. может быть прошли другим способом), то восстановив все "как было" они просто повторят атаку с тем же исходом, даже если вы поменяли все пароли к админке. Нужно устранять саму причину.

Собственно от SQL инъекций защищаться придется так:

1. Самый правильный метод - лезть в код и модифицировать его так, чтобы чистить входные параметры от всяких символов, в первую очередь от ' (полный список чего фильтровать смотрите в инете по теме SQL-injection). Затем писать в саппорт производителя и показывать свой вариант защиты, описывать проблему, ждать пока выпустят заплатку и ставить ее вместо своего самопального решения. Или жить на своем.

2. Также правильно не хранить в базе пароли к админке в открытом виде. Нужно посмотреть что в базе лежит в таблице с юзерами и если там пароли открыты - переписывать блок логина. Далее все как в п.1 - писать в саппорт и ждать апдейта. От дефейса это может и не спасти, поскольку если injection позволяет поменять текст на сайте без авторизации в админке - гадость все равно сделают.

3. Если самому разобраться в этом нельзя - нет опыта, или еще что-то - необходимо как минимум забанить IP адреса с которых шла атака. Реальных хакеров не остановит, но детей можно немного поставить в тупик. Можно банить целую страну, типа Турции, если посетители оттуда не нужны, но я честно говоря не знаю как это сделать чисто админскими средствами (без скрипта и базы по IP).

4. На период проблем можно сделать hardcopy сайта телепортом и пусть они HTML страницы ломают.

5. Вероятно сайт был найден по какой-нибудь строке типа "работает на такой то CMS" в Гугле, маловероятно что им именно этот сайт понадобился. Значит на будущее нужно закрыть максимально возможность распознавания CMS, в частности перевести (например через htaccess) админку на другой URL, вычистить ключевые строки из комментов в шаблонах или что-то еще.

Ну вот я так примерно себе это представляю. Если производитель CMS чесаться по поводу подобных проблем не будет - нужно искать другое решение и переводить сайт на него (жутко дорого и затратно, но иногда другого выхода нет).

вот и эти дефейсеры кстати.

Пример :)

называют себя TurkStorm.Org

называют себя TurkStorm.Org

Верно.

Не совсем. Очистка - это в большинстве случаев излишество.

Входные данные должны

а) приводится к нужному типу (если ожидается число);

б) экранироваться при подстановке в sql-запрос.

Была у MySQL-уязвимость, когда, насколько я понял, пропускались кавычки заданные особым образом, толи хитрым UTFом, толи спецсимволами. Но вроде пофиксили года полтора-два назад.

Правда, насколько актуальны версии у товарища ТС на хостинге - науке неизвестно.

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

Dreammaker,

Версия PHP 4.4.3

Версия MySQL 4.1.16-log

Версия GD 2.0.28

это касательно хостинга информация

Тут можно и поулыбаться %)

У этого товарища не была удалена папка install ! 😂

Чудо, что эти турецкие хацкеры не просекли такого простейшего способа взлома.

Правильно говорят в народе: все гениальное - просто! ☝

Желательно обновить.

Новость с ЛОРа от 03.06.06.

Наши хостеры отличаются тугодумностью :) Вроде бы уже можно и обновить. С другой стороны, "пока работает - не трогай". Правда, в нашем случае это звучит "пока гром не грянет - мужик не перекрестится".. :D