Мини-детектив НЕ системного администратора

[FFunk]

Я вот такой командой смотрю занятое место по директориям:

du --si --max-depth=1

[mobilesfinks]

ещё есть утилита ncdu — даёт более наглядное представление какая папка занимает больше всего места на разделе

[mobilesfinks]

что бы не вспоминать как пишется --max-depth для du, можно использовать ключ -s

du -xhs /*

получим вывод размера всех директорий корневого раздела. Ну и по аналогии с другими папками.

[MasMaX]

Можно еще

du -d 1 -h /

[WaveCut]

Привет, Илья :)

— каким образом попал на сервер?
— есть ли сообщники на других сайтах/директориях?

Есть два распространенных пути подложить веб-шелл: компрометация SSH/FTP/WebDAV или что там у вас, или эксплуатирование уязвимости файлозагрузчика CMS — такое случается регулярно, это далеко не фантастика.
Искать зловред регулярками либо сканнерами безопасности, тут на хабре недавно проскакивала парочка обзоров, не буду рекламировать.
Ну и старайся избегать мэйнстримных и несвежих CMS.

[roskov]

Привет, Валера :-)

Как я написал выше, CMS не моя. Не думаю, что шелл был закинут через SSH/FTP/WebDav (хотя через последнее недавно украли FL.ru насколько я помню). Но безусловно, стоит проверить.

Спасибо за советы!

[TheRaven]

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

[roskov]

Да, пометил в планах, спасибо!

[volanddd]

90% что эксплуатировалась уязвимость в редакторе JCE, 9% что другая уязвимость, вероятность компрометации доступа менее 1%.

[inkvizitor68sl]

debian.pro/1541
secure.php.net/manual/ru/mail.configuration.php

[roskov]

Спасибо большое. То, что нужно.

[digger]

А что такое «рутовский диск»?

[roskov]

Извиняюсь за терминологию. Под этим «невероятным» термином я понимал диск, на котором находится ОС и БД.

Подправил в посте. Спасибо.

[mobilesfinks]

у вас ещё с термином inode недопонятки ))) вы его нодами кличите. Иноды (айноды) тогда уж ))
отсюда понятен флаг "-i" для df и других утилит

[roskov]

Верно, спасибо, исправил :-)

[roskov]

Честно говоря, сначала я написал мануал просто для себя (если вдруг такое повторится снова). Потом пришла мысль поделиться с сообществом — мне бы очень помогла такая статья в тот момент. Это сейчас я уже понимаю, что возможно этого и не стоило делать. Поэтому наверное да, первый блин пост комом.

[raid]

Я вот не понимаю таких людей. По вашему на Хабре вообще ничего писать не нужно.
Если вы с чем-то знакомы и вам не хочется в n-й раз об этом читать — не читайте. А для других информация может оказаться полезной или просто интересной

[ivn86]

информация может оказаться полезной или просто интересной

Полезной я бы счёл информацию поиска зловреда find'ом по дате создания или модификации. Почему-то ни разу такое не встречал. Интересной — демон, отслеживающий inotify'ом модификацию или появление новых сценариев с уведомлением на почту.

[alekciy]

Зловред дату меняет так, что поиск помогает мало. По второму facron например.

[FreeLSD]

Очень распространенная проблема. Правда, как правило, файлы сессий иноды забивают, а не дырявая жумла.
Саппорт мог бы и помочь. Мы всегда помогаем в типовых случаях.

[isden]

> Более того, site.by — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно.

Имхо, вот в эту сторону надо копать после восстановления работы своих. Т.е. просто закрыть его и связаться с владельцем (если, конечно, у вас там не какой-то жесткий договор на его обслуживание).
Хостить какую-то левую фигню, которая непонятно что делает, как-то не очень гут, имхо.

[Iforgot]

Ну правильно, вы бы в саппорт написали: у меня мускул не взлетает — закончилось место! А проблема то не в месте, проблема что спамят с вашего железа. Админ бы почистил диск, получил бы место, мускул бы взлетел, но на недолго. Вы бы опять обратились в саппорт: как же так, я платил, а мускул и недели не проработал!

В общем, правильно заданный вопрос — половина ответа. Ваш сервер — обычный спам релей, ломанули старую уязвимость на сайте и залили 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 — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно

Вы считаете нормальным держать на своем продакшен-сервере такие проекты?

[amarao]

Сказать честно, на нескольких миллиардах файлов в одном каталоге, проще новую FS сделать. rm такого чуда, только если продакшен позволяет, в screen/nohup, с ожиданием «за недельку разгребёт».

[isden]

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

[amarao]

Не настолько, чтобы это сильно помогло. Там основная проблема — удаление всё ещё остаётся более дорогой операцией, чем добавление, да ещё и со сложностью районе o(что-то-от-числа-файлов-в-каталоге). Удалить миллиард файлов из тысячи каталогов в кажом из которых по тысяче каталогов в каждом из которых по тысяче файлов? Может быть. Удалить каталог с миллиардом файлов? Не в этой жизни.

[isden]

Хочется мне посмотреть на каталог с миллиардом файлов… Поискал тут в интернетах — пишут, что синтетическими тестами не удавалось набить больше 10-20 миллионов, потом начинались проблемы с журналом, приходилось жестко тюнить (ext4).
Из личного опыта — работа с каталогом при паре миллионов уже начинает очень заметно подтормаживать. Видел такое у одного клиента.