Я использую Ubuntu 12.04 x64 VPS с Vesta и сайт на PHP. Его несколько раз взламывали с помощью внедренного кода, который выглядит так:
<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....
Чтобы исправить это, я решил изменить разрешения и владельца всех файлов на 555 и root, чтобы ни один пользователь не мог изменять файлы. Я удалил доступ по FTP и защитил SSH, так что только ключи, которые у меня есть в VPS, могут подключаться.
Несмотря на все эти изменения, другой пользователь всегда может изменить файлы, переименовать папки и загрузить другой взломанный файл.
Что, по-вашему, я упускаю? Есть предложения? Спасибо! Если вам нужна дополнительная информация по этой проблеме, я буду рад поделиться ею, чтобы помочь другим, страдающим от того же зла!
решение1
Атакующий получил root-доступ к вашей системе. Вы не можете доверять НИЧЕМУ в системе, вообще. Масштаб того, что может сделать руткит, огромен.
Если у вас где-то есть резервные копии вашего контента, используйте их. В противном случае вы можете надеяться, что злоумышленник не испортил ваши данные. Скопируйте ваши таблицы SQL и скопируйте их вместе с другими материалами (jpg, pdf, 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.
решение2
Если вы можете этого избежать, вам не следует запускать процессы веб-сервера от имени пользователя root, поскольку это означает, что компрометация любой уязвимости в веб-службе полностью поставит под угрозу сервер.
Учитывая, где вы сейчас находитесь, я бы рекомендовал начать с нуля на новом сервере — злоумышленник мог получить себе постоянный root-доступ любым из множества способов. СмотретьздесьЧтобы получить больше информации.
решение3
Несмотря на все эти изменения, другой пользователь всегда может изменить файлы, переименовать папки и загрузить другой взломанный файл.
Если родительский каталог вашего корневого веб-каталога принадлежит тому же пользователю, который запускает веб-сервер, то разрешения для этого родительского каталога переопределят любые разрешения, установленные для дочерних файлов и каталогов.
Например, откройте процесс «Терминал» в любом каталоге, которым вы владеете. Теперь создайте файл с 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, который уязвим для атак, этот плагин следует обновить/исправить, чтобы закрыть дыру.
И помимо всего этого, ваше основное системное программное обеспечение (предполагается, что это стек LAMP (Linux Apache MySQL PHP)) также должно обновляться и патчиться.
В конце концов, безопасность веб-сайта — это не просто одноразовая вещь. Это общая ментальность и процесс обслуживания, которых необходимо придерживаться. В противном случае, когда ваш сайт взломают, вы будете работать без головы в попытках навести порядок, что на самом деле может нанести больший ущерб, чем первоначальное вторжение вредоносного ПО.
решение4
Я согласен начать с варианта с сервера, но если вам нужна большая безопасность и контроль, выделенный сервер — лучшая идея.
Что касается вашей ситуации, первое, что я предлагаю, это отключить все запущенные службы, кроме доступа к оболочке. Это означает остановку службы FTP, веб-сервера (HTTP), электронной почты и т. д. и т. п. Затем перейдите в оболочку и перейдите к папкам, содержащим элементы, которые, как вы утверждаете, были взломаны. Затем введите:
ls -al
В результатах вы должны увидеть что-то похожее на следующее:
drwxrwxrwx 2 root root 4096 2014-10-10 00:31 ./
Если четвертый элемент (или особенно третий элемент) на самом деле "root", то у вас большие проблемы, и вам нужно переделать конфигурацию вашего веб-сервера, чтобы он выполнял действия от имени разных пользователей в зависимости от папки. Вам следует изучить mod_rewrite (или аналогичный) для apache, а затем соответствующим образом настроить файл конфигурации apache (httpd.conf), чтобы система меняла имя пользователя при каждом запросе к папке. Затем измените имя пользователя и имя группы папки соответствующим образом.
После исправления этой ошибки перейдите в корневую папку документа (скорее всего, public_html), используйте редактор (например, pico) и введите следующее:
<?php
echo shell_exec("whoami");
?>
затем сохраните его как who.php. Затем включите веб-сервер и в любом браузере перейдите на домашнюю страницу вашего сайта, но добавьте who.php в конец, и вы должны увидеть только одно слово на экране. Если это слово root, то у вас большие проблемы и вам нужно снова выполнить вышеуказанные шаги. Если слово nobody, то у вас небольшие проблемы, потому что хакеры очень хорошо знают это имя пользователя.