Я запускаю Ubuntu 12.04 x64 VPS с Vesta и сайт на PHP. Его несколько раз взламывали с помощью внедренного кода, который выглядит следующим образом:
<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....
Чтобы исправить это, я решил изменить права доступа и владельца всех файлов на 555 и root, чтобы ни один пользователь не мог изменять файлы. Я удалил FTP-доступ и защитил SSH, поэтому только ключи, которые у меня есть на VPS, могут подключаться.
Несмотря на все эти изменения, другой пользователь всегда может изменить файлы, переименовать папки и загрузить еще один взломанный файл.
Как вы думаете, что мне не хватает? Любое предложение? Спасибо! Если вам нужна дополнительная информация по этому вопросу, я буду рад поделиться, чтобы помочь другим, страдающим от того же зла!
Если вы можете этого избежать, вы не должны запускать процессы веб-сервера от имени пользователя root, поскольку это означает, что компрометация любой уязвимости в веб-службе полностью скомпрометирует сервер.
В том месте, где вы сейчас находитесь, я бы рекомендовал начать с нуля на новом сервере - злоумышленник мог предоставить себе постоянный root-доступ с помощью любого количества методов. Видеть Вот Чтобы получить больше информации.
Несмотря на все эти изменения, другой пользователь всегда может изменить файлы, переименовать папки и загрузить еще один взломанный файл.
Если родительский каталог вашего корневого веб-каталога принадлежит тому же пользователю, который запускает веб-сервер, тогда эти разрешения родительского каталога будут переопределять любые разрешения, установленные для дочерних файлов и каталогов.
Например, откройте процесс «Терминал» в любом принадлежащем вам каталоге. Теперь создайте файл с именем zzz_test.txt как это:
touch zzz_foo.txt
Теперь проверьте файл вот так:
ls -la zzz_foo.txt
Разрешения - в моем случае - выглядят так:
-rw-r--r-- 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Тогда я бегу chmod как это:
chmod 555 zzz_foo.txt
Теперь беги ls -la снова и результат будет выглядеть так:
-r-xr-xr-x 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Ладно, разрешения изменены. Итак, давайте сделаем что-нибудь «безумное», например, попытаемся удалить его:
rm zzz_foo.txt
Ответ будет таким:
override r-xr-xr-x jack/staff for zzz_foo.txt?
А затем просто нажмите y и нажмите возвращение и альт! Файл пропал.
Вот почему простое изменение прав доступа к файлам никогда не будет эффективным способом защиты веб-сервера. Простая природа работы веб-серверов, особенно если она основана на PHP, означает, что пользователь веб-сервера всегда будет иметь доступ для чтения и записи к файлам, к которым он должен получить доступ. Так что просто идти chmod 555 [some files] это неэффективный способ «защитить» себя от вредоносных программ и попыток взлома.
Что вы можете сделать сейчас? Что ж, простое изменение разрешений и владения ничего не значит. Более серьезная проблема заключается в том, что ваша кодовая база PHP уязвима для атак. Итак, единственный эффективный способ избавиться от подобных вещей - это очистить свой PHP-код. Если этот сайт основан на стандартном фреймворке, таком как Joomla !, WordPress или CakePHP, то лучший способ действий - обновить базовый фреймворк Joomla !, WordPress или CakePHP, чтобы включить блокировку безопасности. Точно так же, если есть плагин Joomla !, WordPress или CakePHP, уязвимый для атак, этот плагин следует обновить / пропатчить, чтобы закрыть дыру.
И помимо всего этого, ваше основное системное программное обеспечение - если это L.A.M.P. Стек (Linux Apache MySQL PHP) - также необходимо обновлять и исправлять.
В конце концов, безопасность веб-сайта - это не разовая вещь. Это общий менталитет и процесс обслуживания, которого необходимо придерживаться. В противном случае, когда ваш сайт будет взломан, вы будете работать без головы, пытаясь устранить беспорядок, который на самом деле может нанести больший ущерб, чем само первоначальное вторжение вредоносного ПО.
Я согласен начать с варианта сервера, но если вы хотите большей безопасности и контроля, выделенный сервер - лучшая идея.
Что касается вашей ситуации, первое, что я предлагаю, - это отключить все запущенные службы, кроме доступа к оболочке. Это означает остановку службы FTP, веб-сервера (HTTP), электронной почты и т. Д. Затем войдите в оболочку и перейдите к папкам, содержащим элементы, которые, как вы утверждали, были взломаны. затем введите:
ls -al
В результате вы должны увидеть что-то похожее на следующее:
drwxrwxrwx 2 root root 4096 2014-10-10 00:31 ./
Если четвертый элемент (или особенно третий элемент) на самом деле является «корневым», то у вас серьезные проблемы, и вам необходимо переделать конфигурацию вашего веб-сервера, чтобы он выполнял действия от имени разных пользователей в зависимости от папки. Вы должны изучить mod_rewrite (или аналогичный) для apache, а затем соответствующим образом настроить файл конфигурации apache (httpd.conf), чтобы система меняла имя пользователя при каждом запросе к папке. Затем измените имя пользователя и имя группы папки соответственно.
Как только это будет исправлено, перейдите в корневую папку документа (вероятно, public_html), используйте редактор (pico работает) и введите следующее:
<?php
echo shell_exec("whoami");
?>
затем сохраните его как who.php. Затем включите веб-сервер и в любом браузере перейдите на домашнюю страницу своего веб-сайта, но добавьте who.php в ее конец, и вы увидите только одно слово на экране. Если это слово является корнем, значит, у вас большие проблемы, и вам нужно повторить вышеуказанные шаги снова. Если это слово «никто», то у вас проблемы, потому что хакеры очень хорошо знают это имя пользователя.
Злоумышленник получил root права на вашу систему. Вы вообще не можете доверять НИЧЕМУ в системе. Возможности руткита огромны.
Если у вас где-то есть резервные копии вашего контента, используйте их. В противном случае вы можете надеяться, что злоумышленник не испортил ваши данные. Сбросьте свои таблицы SQL и скопируйте их вместе с другими вашими материалами (jpgs, pdfs, html, но НЕ какие-либо скрипты / php / что-либо еще, что будет выполнено). Скопируйте его в другую систему или загрузите на домашний компьютер, если он достаточно мал, чтобы вы могли загрузить его снова.
Сделайте все возможное, чтобы убедиться, что то, что вы скопировали, все еще в порядке. (например, на всякий случай проверьте, что все jpg-файлы являются действительными. Может быть, запустить на них антивирусный сканер?)
Удалите скомпрометированную установку. Если ваш сервер размещен на типичной службе хостинга, то, надеюсь, у них все настроено, так что у вас есть панель управления, которую нельзя испортить даже с помощью root на хосте. Так что вы можете надеяться, что злоумышленнику не удалось прикоснуться к чему-либо за пределами взломанной машины. (Если у вас был беспарольный доступ к чему-либо еще, настроенному на этой машине, проверьте их.)
Сделайте все возможное, чтобы выполнить новую установку. Можно также перейти на Ubuntu 14.04 LTS, так как вам все равно придется переустановить.
НЕ копируйте код из взломанной системы в новую систему. Со всеми данными, поступающими из взломанной системы, следует обращаться как с потенциальным носителем чумы.
Семантика файловой системы Unix требует разрешения на запись в каталог для удаления файлов. (имена файлов - это ссылки от имени на индексный дескриптор. Системный вызов для создания жестких ссылок (других имен для файла) link(2), а призыв к удалению файла - unlink(2).)
Если бит залипания установлен в каталоге (chmod +t), unlink(2) и rename(2) также требовать, чтобы вызывающий владел файлом, который нужно отсоединить или переименовать. (независимо от разрешения на запись в файл). Это стандарт для /tmp и /var/tmp быть 1777 (мир записывается с установленным липким битом).
rm, команда оболочки, требуется POSIX чтобы запросить перед отключением файлов, предназначенных только для чтения, но он должен проверить этот случай. На самом деле ему не нужно делать ничего, кроме unlink(2) как и для любого другого файла. Так что не дайте себя обмануть, думая, что это хоть как-то влияет на противника.
Ничто из этого не имеет большого отношения к защите от атак, потому что наиболее вероятным случаем является получение контроля над процессом вашего веб-сервера или чем-то еще, работающим с идентификатором пользователя, у которого есть доступ для записи ко многим вещам.
Чем больше вы можете ограничить то, что может быть написано процессами, имеющими дело с данными из Интернета, тем меньше у злоумышленника шансов перейти от получения контроля над вашим httpd к изменению ваших данных или получению контроля над всей вашей машиной.
Вот почему вам не следует запускать apache от имени пользователя root.