Установлены права доступа 555. Как другой пользователь может изменять файлы? [дубликат]
На этот вопрос уже есть ответ здесь:
- Как мне справиться с взломанным сервером? 13 ответов
Я запускаю Ubuntu 12.04 x64 VPS с Vesta, и сайт на PHP. Его несколько раз взламывали с помощью внедрения кода, который выглядит следующим образом:
<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....
Чтобы исправить это, я решил изменить права доступа и владельца всех файлов на 555 и root, чтобы ни один пользователь не мог изменять файлы Я удалил доступ по FTP и защитил SSH, так что только ключи, которые у меня есть на VPS, могут подключаться.
Несмотря на все эти изменения, другой пользователь всегда может изменять файлы, переименовывать папки и загружать другой взломанный файл.
Как вы думаете, чего мне не хватает? Есть предложения? Спасибо! Если вам нужна дополнительная информация по этой проблеме, я буду рад поделиться, чтобы помочь другим, страдающим от того же зла!
Злоумышленник получил root-права в вашей системе. Вы вообще не можете доверять НИЧЕМУ в системе. Возможности руткита огромны.
Если у вас где-то есть резервные копии вашего контента, используйте их. В противном случае вы можете надеяться, что злоумышленник не испортил ваши данные. Сбросьте свои таблицы SQL и скопируйте их вместе с другими вашими материалами (jpgs, pdfs, html, но НЕ какие-либо скрипты / php / что-либо еще, что будет выполнено). Скопируйте его в другую систему или загрузите на свой домашний компьютер, если он достаточно мал, чтобы вы могли загрузить его снова.
Сделайте все возможное, чтобы убедиться, что то, что вы скопировали, все еще в порядке. (например, на всякий случай проверьте, что все jpg-файлы все еще действительны. Может быть, запустить на них антивирусный сканер?)
Удалите скомпрометированную установку. Если ваш сервер размещен на типичной службе хостинга, то, надеюсь, у них есть все настроенные, так что у вас есть панель управления, которую нельзя испортить даже с помощью root на хосте. Таким образом, вы можете надеяться, что злоумышленник не смог прикоснуться к чему-либо за пределами взломанной машины. (Если у вас был беспарольный доступ к чему-либо еще, настроенному на этой машине, проверьте их.)
Сделайте все, что вам нужно, чтобы выполнить новую установку. Можно также перейти на Ubuntu 14.04 LTS, так как вам все равно придется переустановить.
НЕ копируйте код из скомпрометированной системы в новую систему. Со всеми данными, поступающими из скомпрометированной системы, следует обращаться как с потенциальным носителем чумы.
Семантика файловой системы Unix требует разрешения на запись в каталог для удаления файлов. (имена файлов - это ссылки от имени на индексный дескриптор. Системный вызов для создания жестких ссылок (другие имена для файла) - это ссылка (2) , а вызов для удаления файла - unlink (2 ) .)
Если бит закрепления установлен в каталоге ( chmod + t ), unlink (2) и rename (2) также требуют, чтобы вызывающий владел файлом, который нужно отсоединить или переименовать. (независимо от разрешения на запись в файл). Стандартно для / tmp и / var / tmp должно быть 1777 (всемирная запись с набором липких битов).
rm , оболочка POSIX требует, чтобы команда выводила запрос перед отключением файлов, доступных только для чтения, но она должна проверять этот случай. На самом деле ему не нужно делать ничего, кроме unlink (2) , как это было бы с любым другим файлом. Так что не дайте себя обмануть, думая, что это хоть как-то влияет на противника.
Ничто из этого не имеет большого отношения к защите от атак, потому что наиболее вероятным случаем является получение контроля над процессом вашего веб-сервера или что-то еще который работает с идентификатором пользователя, у которого есть доступ для записи ко многим вещам.
Чем больше вы можете ограничить то, что может быть записано процессами, которые имеют дело с данными из Интернета, тем меньше вероятность того, что злоумышленнику, чтобы перейти от получения контроля над вашим httpd к изменению ваших данных или получению контроля над всей вашей машиной.
Вот почему вам не следует запускать apache от имени пользователя root.
Если вы можете этого избежать, вам не следует запускать процессы веб-сервера от имени пользователя 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 и нажмите return и альт! Файл пропал.
Вот почему простое изменение прав доступа к файлу никогда не будет эффективным способом защиты веб-сервера. Простая природа работы веб-серверов - особенно если она основана на PHP - означает, что пользователь веб-сервера всегда будет иметь доступ для чтения и записи к файлам, к которым он должен получить доступ. Так что простое выполнение chmod 555 [some files] - неэффективный способ «защитить» себя от вредоносных программ и попыток взлома.
Что вы можете сделать сейчас? Ну, простое изменение разрешений и владения ничего не значит. Более серьезная проблема заключается в том, что ваша кодовая база PHP уязвима для атак. Итак, единственный эффективный способ избавиться от подобных вещей - это очистить свой PHP-код. Если этот сайт основан на стандартном фреймворке, таком как Joomla !, WordPress или CakePHP, то лучший способ действий - обновить базовый фреймворк Joomla !, WordPress или CakePHP, чтобы включить блокировку безопасности. Точно так же, если есть плагин Joomla !, WordPress или CakePHP, уязвимый для атак, этот плагин следует обновить / пропатчить, чтобы закрыть дыру.
И помимо всего этого, ваше основное системное программное обеспечение - при условии, что это ФОНАРЬ Стек (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 в ее конец, и вы должны увидеть только одно слово на экране. Если это слово является корнем, значит, у вас серьезные проблемы и вам нужно повторить описанные выше шаги снова. Если это слово «никто», то у вас проблемы, потому что хакеры очень хорошо знают это имя пользователя.