Комментарии 29
Я вот такой командой смотрю занятое место по директориям:
du --si --max-depth=1
Привет, Илья :)
Есть два распространенных пути подложить веб-шелл: компрометация SSH/FTP/WebDAV или что там у вас, или эксплуатирование уязвимости файлозагрузчика CMS — такое случается регулярно, это далеко не фантастика.
Искать зловред регулярками либо сканнерами безопасности, тут на хабре недавно проскакивала парочка обзоров, не буду рекламировать.
Ну и старайся избегать мэйнстримных и несвежих CMS.
— каким образом попал на сервер?
— есть ли сообщники на других сайтах/директориях?
Есть два распространенных пути подложить веб-шелл: компрометация SSH/FTP/WebDAV или что там у вас, или эксплуатирование уязвимости файлозагрузчика CMS — такое случается регулярно, это далеко не фантастика.
Искать зловред регулярками либо сканнерами безопасности, тут на хабре недавно проскакивала парочка обзоров, не буду рекламировать.
Ну и старайся избегать мэйнстримных и несвежих CMS.
Привет, Валера :-)
Как я написал выше, CMS не моя. Не думаю, что шелл был закинут через SSH/FTP/WebDav (хотя через последнее недавно украли FL.ru насколько я помню). Но безусловно, стоит проверить.
Спасибо за советы!
Как я написал выше, CMS не моя. Не думаю, что шелл был закинут через SSH/FTP/WebDav (хотя через последнее недавно украли FL.ru насколько я помню). Но безусловно, стоит проверить.
Спасибо за советы!
Joomla, особенно старая — швейцарский сыр, а боты ходят по ним часто. Посмотрите список плагинов которые установлены и прогуглите на тему известных уязвимостей, иначе история будет повторяться.
90% что эксплуатировалась уязвимость в редакторе JCE, 9% что другая уязвимость, вероятность компрометации доступа менее 1%.
А что такое «рутовский диск»?
НЛО прилетело и опубликовало эту надпись здесь
Честно говоря, сначала я написал мануал просто для себя (если вдруг такое повторится снова). Потом пришла мысль поделиться с сообществом — мне бы очень помогла такая статья в тот момент. Это сейчас я уже понимаю, что возможно этого и не стоило делать. Поэтому наверное да, первый блин пост комом.
Я вот не понимаю таких людей. По вашему на Хабре вообще ничего писать не нужно.
Если вы с чем-то знакомы и вам не хочется в n-й раз об этом читать — не читайте. А для других информация может оказаться полезной или просто интересной
Если вы с чем-то знакомы и вам не хочется в n-й раз об этом читать — не читайте. А для других информация может оказаться полезной или просто интересной
информация может оказаться полезной или просто интересной
Полезной я бы счёл информацию поиска зловреда find'ом по дате создания или модификации. Почему-то ни разу такое не встречал. Интересной — демон, отслеживающий inotify'ом модификацию или появление новых сценариев с уведомлением на почту.
НЛО прилетело и опубликовало эту надпись здесь
Очень распространенная проблема. Правда, как правило, файлы сессий иноды забивают, а не дырявая жумла.
Саппорт мог бы и помочь. Мы всегда помогаем в типовых случаях.
Саппорт мог бы и помочь. Мы всегда помогаем в типовых случаях.
> Более того, site.by — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно.
Имхо, вот в эту сторону надо копать после восстановления работы своих. Т.е. просто закрыть его и связаться с владельцем (если, конечно, у вас там не какой-то жесткий договор на его обслуживание).
Хостить какую-то левую фигню, которая непонятно что делает, как-то не очень гут, имхо.
Имхо, вот в эту сторону надо копать после восстановления работы своих. Т.е. просто закрыть его и связаться с владельцем (если, конечно, у вас там не какой-то жесткий договор на его обслуживание).
Хостить какую-то левую фигню, которая непонятно что делает, как-то не очень гут, имхо.
Ну правильно, вы бы в саппорт написали: у меня мускул не взлетает — закончилось место! А проблема то не в месте, проблема что спамят с вашего железа. Админ бы почистил диск, получил бы место, мускул бы взлетел, но на недолго. Вы бы опять обратились в саппорт: как же так, я платил, а мускул и недели не проработал!
В общем, правильно заданный вопрос — половина ответа. Ваш сервер — обычный спам релей, ломанули старую уязвимость на сайте и залили php код.
Вот навскидку еще пара подсобных инструментов:
Показывает количество в очереди писем (просто цифру)
exim -bpc
вот эти команды чистят очередь:
exipick -zi | xargs exim -Mrm
exipick -i | xargs exim -Mrm
exiqgrep -o 0 -i | xargs exim4
затем надо в php.ini включить:
mail.add_x_header = On
mail.log = /var/www/phpmail.log
Эта штука будет в лог писать путь до php файла, который рассылает спам. Пока вы не обновили дырявый опенсорсный движок, php файлы будут к вам заливаться до бесконечности. Но хотя бы на пару часов можно прибить виновника, чтобы снять нагрузку с проца и нормально решить проблему )
>Более того, site.by — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно
Вы считаете нормальным держать на своем продакшен-сервере такие проекты?
В общем, правильно заданный вопрос — половина ответа. Ваш сервер — обычный спам релей, ломанули старую уязвимость на сайте и залили php код.
Вот навскидку еще пара подсобных инструментов:
Показывает количество в очереди писем (просто цифру)
exim -bpc
вот эти команды чистят очередь:
exipick -zi | xargs exim -Mrm
exipick -i | xargs exim -Mrm
exiqgrep -o 0 -i | xargs exim4
затем надо в php.ini включить:
mail.add_x_header = On
mail.log = /var/www/phpmail.log
Эта штука будет в лог писать путь до php файла, который рассылает спам. Пока вы не обновили дырявый опенсорсный движок, php файлы будут к вам заливаться до бесконечности. Но хотя бы на пару часов можно прибить виновника, чтобы снять нагрузку с проца и нормально решить проблему )
>Более того, site.by — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно
Вы считаете нормальным держать на своем продакшен-сервере такие проекты?
Сказать честно, на нескольких миллиардах файлов в одном каталоге, проще новую FS сделать. rm такого чуда, только если продакшен позволяет, в screen/nohup, с ожиданием «за недельку разгребёт».
У меня есть сильные подозрения, что если перемонтировать раздел без журналирования, то процесс очень сильно ускорится.
Не настолько, чтобы это сильно помогло. Там основная проблема — удаление всё ещё остаётся более дорогой операцией, чем добавление, да ещё и со сложностью районе o(что-то-от-числа-файлов-в-каталоге). Удалить миллиард файлов из тысячи каталогов в кажом из которых по тысяче каталогов в каждом из которых по тысяче файлов? Может быть. Удалить каталог с миллиардом файлов? Не в этой жизни.
Хочется мне посмотреть на каталог с миллиардом файлов… Поискал тут в интернетах — пишут, что синтетическими тестами не удавалось набить больше 10-20 миллионов, потом начинались проблемы с журналом, приходилось жестко тюнить (ext4).
Из личного опыта — работа с каталогом при паре миллионов уже начинает очень заметно подтормаживать. Видел такое у одного клиента.
Из личного опыта — работа с каталогом при паре миллионов уже начинает очень заметно подтормаживать. Видел такое у одного клиента.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мини-детектив НЕ системного администратора