- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Потому что сливают только длешные базы в этом случае. Длешные хакеры :D
Значит база DLE как-то связана с уязвимостью ПМА. Целенаправленная атака.
Palad1n, такой вопрос, а можно этот модуль phpMyAdmin вообще выключать, когда он не нужен? так будет безопаснее всего, я думаю... что скажете? он ведь никак не влияет на текущую работу сервера и сайтов на нём, верно? а когда нужно, то включать его в isp manager на время работы с базами
Schmied, абсолютно верно. На работу сервера и сайтов никак не влияет.
Многие так и делают.
Но папку setup и файл documentation в пма лучше спрятать.
А можно имея доступ к ПМА (зная его айпи и пару логин/пароль) автоизоваться и делать запросы через пхп-скрипт?
Там просто куки используются, поэтому я не уверен что можно.
Но, если это возможно, то хакер мог просто после получения пароля от БД, искать по тому же айпи на хосте ПМА и если скрипт его находил, то логинился и делал свои черные делишки.
Но папку setup и файл documentation в пма лучше спрятать.
да, папку я переименоваал, а файлик вообще удалил.
в общем, вырубил я этот ПМА, думаю, так будет лучше всего.
ещё раз спасибо за ценные советы. :)
А можно имея доступ к ПМА (зная его айпи и пару логин/пароль) автоизоваться и делать запросы через пхп-скрипт?
Там просто куки используются, поэтому я не уверен что можно.
Но, если это возможно, то хакер мог просто после получения пароля от БД, искать по тому же айпи на хосте ПМА и если скрипт его находил, то логинился и делал свои черные делишки.
Исходя из ваших слов, длля начала хакеру нужно получить логин и пароль к пма. Если он их получит, то тогда ему вобще ничего ломать и узнавать не нужно. Он может взять и просто удалить все бд из mysql.
Тут ведь шли массовые атаки на длешные сайты, хакер ведь не мог знать логин и пароль сразу у всех этих людей? :)
Посмотрите офиц. текст на сайте разработчиков ПМА: phpmyadmin.net/home_page/security/PMASA-2012-5.php
Данному багу присвоено значение критическое!
Уязвимые версии: phpMyAdmin 3.5.2.2
Уязвимость позволяет удаленному пользователю выполнить произвольный код на целевой системе.
Уязвимость существует из-за наличия бэкдора в исходном коде phpMyAdmin-3.5.2.2-all-languages.zip (файл server_sync.php), доступном через зеркало "cdnetworks-kr-1" SourceForge. Удаленный пользователь может выполнить произвольный PHP код на целевой системе.)
Остальные баги можете посмотреть на той же странице для всех версий ПМА.
Schmied, хорошее решение, но по возможности лучше перейдите на свежую версию.
Исходя из ваших слов, длля начала хакеру нужно получить логин и пароль к пма. Если он их получит, то тогда ему вобще ничего ломать и узнавать не нужно. Он может взять и просто удалить все бд из mysql.
Про уязвимость я не спорю.
Просто например у меня доступ к ПМА по ссылке: https://(ip моего VDS)/myadmin/
Там сразу окошко авторизации, я могу зайти под любым MySQL юзером и паролем через это окошко.
Конечно, если эти юзеры есть в базе и пароль подходит.
Т.е. зачем мне пароль от самого ПМА, если можно через интерфейс ПМА войти в нужную базу, если известен логин и пароль юзера в БД.
---------- Добавлено 21.09.2013 в 17:57 ----------
Т.е. алгоритм взломщика может быть таким:
1) Взломал DLE через дыру и узнал логин/пароль от базы
2) Потом сканирует все типичные расположения ПМА на том же ip, где расположен взломанный сайт и если находит их на своем месте, то заходит в базу, логин и пароль от который был добыт в пункте 1
3) Вручную или скриптом дописывает в поле dle_post (и еще в стат. страницы) свой вредоносный код.
edka, я Вас понял.
И такое могло быть.
Поэтому лучше либо обновить ПМА, либо переименовать путь к нему, либо закрыть его и открывать только в нужное время.
Какая цель конкретная преследовалась при добавлении этого кода в посты друшлака под именем ДЛЕ ? P.S. после первой чистки уже сколько дней назад зараза более не появлялась... Кстати насчет phpmyadmin, заражение повторное не происходило с даты моего создания этого топика, а адмиша был включен на сервере все это время... ДЛЕ был друшлаком и будет оставаться им еще долгое время -ИМХО. И кстати насчет ввода новых функций создателями скрипта, хочу сказать одно - вы предыдущие до ума доведите, а не каждые 2 месяца новую версию дуйте! Конечно цена копеечная за сее творение, но та же joomla надежней и бесплатная. Ладно, наболело... Понятное дело что выявить все уязвимости невозможно да и не нужно этого делать, но скорость отклика поражает. Кто им после этого деньги то заплатить захочет.
ДЛЕ дурщлак не дуршлакее других движков. Просто он был и остается самым массовым и популярным, поэтому и отзывов по нему больше. Как положительных, так и негативных.
Грубо говоря, так, для примера, если имеем всего сайтов на Джумле 10 (при 1 случаи взлома), сайтов на Вордпресс 50 (при 3 случаях взлома), сайтов на ДЛЕ 1000 (при 50 случаях взлома) - так в каком варианте будут громче и больше кричать о дуршлаке? А ситуация, в принципе, такая и есть. Ломают все движки. Просто чем популярней - тем заявленных случаев больше.