У меня проблемы с пониманием того, какие проблемы могут вызывать случайные зависания сервера из-за внезапных скачков нагрузки. Я не системный администратор (я программист PHP), но, поскольку официальному системному администратору не хватает усилий, меня просят найти решение самостоятельно.
Сервер работает на Debian Lenny и обслуживает через apache сайт на основе wordpress + vbulletin с 40-60 тысячами посещений в день. Выполнив всю возможную оптимизацию на стороне приложения, мы дошли до ситуации, когда сайт работает без сбоев даже в течение нескольких недель, а затем отключается от чего-то, что заставляет нагрузку на сервер подскакивать до 80+. Остановка apache для его перезапуска помогает, но обычно она успокаивается сама по себе, если дать достаточно времени. Он может «вылетать» дважды в день или не замечать проблем в течение нескольких недель. Кажется, это совершенно случайно.
Однако произошла одна странная особенность. Меня предупредили о странном поведении, и после осмотра я обнаружил .htaccess файл изменен для перенаправления трафика с поисковых систем на внешний сайт. Я проверил код и все плагины (все в актуальном состоянии) и, наконец, попробовал "на собственном опыте" chowning .htaccess к root.root. Странно то, что, когда возникла другая проблема, я обнаружил, что этот файл снова стал принадлежать пользователю, назначенному виртуальному хосту веб-сайта. Я понимаю, что это не может произойти только через какой-то веб-эксплойт, или я ошибаюсь?
Как я могу найти причину резких скачков нагрузки?
Что может объяснить root.root разрешения на изменение файлов, кроме того, что это делает кто-то с root-доступом?
Могут ли эти две вещи быть связаны с какой-то атакой?
Что касается проблемы с Apache, одна из возможных причин - слишком высокий параметр MaxClient / MaxServer. Когда вы получаете всплеск трафика, вы используете всю свою оперативную память и заставляете Apache начать использовать своп, что очень быстро снижает вашу производительность. В следующий раз, когда у вас возникнет проблема, проверьте вывод top / free и посмотрите, не используется ли какой-либо своп. Если это так, попробуйте уменьшить значения MaxClient / MaxServer.
У меня также была проблема с Apache 1.3, когда некоторые соединения никогда не закрывались, и через несколько дней 90% соединений ничего не делали, оставляя клиентов для обработки входящих новых соединений. Я решил это, просто перезагружая Apache каждый день. Судя по звукам, у вас недостаточно трафика или времени между проблемами, чтобы это было вероятной причиной.
Я понимаю, что это не может произойти только через какой-то веб-эксплойт, или я ошибаюсь?
Само по себе это не будет учитывать разрешения на изменение файла, принадлежащего root: root, но веб-компрометация может позволить злоумышленнику развернуть вредоносное ПО в системе, которое может скомпрометировать систему другими способами. Есть и другие способы скомпрометировать систему.
Если вы уверены, что ваш код не был изменен с момента последней проверки, то пора устранить все остальное - использование средств проверки руткитов - хорошая идея для системы, которую вы считаете безопасной, - но если у вас есть сомнения, вам следует переформатировать / переустановить.
Может это нападение, но тогда зачем менять только .htaccess файл, наверное, есть еще что проверить. Возможно, скрипты php автоматически генерируют файл. Какие разрешения у файла?
Что касается нагрузки, то это может быть много чего, тем более что она случайна. Следите за журналами и используйте инструменты (webalizer, чтобы увидеть, совпадают ли всплески нагрузки с длительным временем доступа или доступом к определенному ресурсу, который может иметь место.
Проверьте свой сервер с помощью chkrootkit и аналогичные инструменты для проверки на компромисс. Если это произошло, вам может потребоваться / вы захотите переустановить сервер с нуля.
Мне кажется, что кто-то скомпрометировал ваш сервер, скорее из-за перенаправления трафика поисковой системы на другой сайт, чем из-за проблемы владения файлом. Боюсь, что некоторые веб-эксплойты могут дать злоумышленнику root-доступ к вашей системе.
Я бы загрузил и запустил детектор руткитов, например Руткит-охотник. если ты иметь были внедрены, вы, вероятно, захотите, чтобы кто-то опытный помог вам исправить это.
На веб-сервере запустить # ps -uapache -o wchan=WIDE-WCHAN-COLUMN,cmd попробуйте найти что-то похожее на flock_lock_file_w /usr/sbin/httpd на первом поле.
Какой твой session.save_handler?