Почему read-only файл не гарантирует защиту от изменения

Почему read-only файл не гарантирует защиту от изменения
При взломе сайта с целью заработка или распространения вредоносного программного обеспечения в файлах скриптов и шаблонов размещается вредоносный код, такой как вирусные вставки, хакерские шеллы, бэкдоры и т.п. Хакеры модифицируют файлы скриптов, шаблонов и настроек, а владельцы сайта, как умеют, пытаются свой сайт защитить.  Например, запретить запись в те файлы, в которые хакеры добавляют вредоносный код, делая их “только для чтения”. Особенно сообразительные администраторы и веб-мастера меняют у файла владельца на root, что уж точно должно гарантировать защиту от изменения. Но спустя некоторое время обнаруживают, что в файле снова добавлен вредоносный код, при этом у файла сохранилась дата, время и атрибуты “только для чтения”. То есть случилась магия.

Очень часто подобная картина наблюдается у файлов .htaccess и индексных (index.php, index.html). В действительности никакой магии нет. Просто есть масса способов изменять содержимое read-only файла и одна только смена атрибутов на 400 или 444 не дает нужного эффекта. Рассмотрим варианты изменения read-only файла всеми доступными на хостинге средствами, включая php скрипты:
  1. Просто разрешить запись: самый очевидный способ – прочитать текущие атрибуты, поменять их с помощью chmod(“…”), system(“chmod …”) и т.п., после чего дописать в файл код и снова поменять атрибуты на старые. Если включить сюда сохранение и восстановление даты и времени файла, то вообще сложно будет заметить какие-то изменения. При определенных условиях можно даже сохранять размер файла.
  2. По FTP: подключиться, разрешить запись в файл, изменить файл, затем снова поменять права на readonly
  3. По SSH: подключиться, разрешить запись в файл, изменить файл, затем снова поменять права на readonly
  4. Пересоздать файл: прочитать содержимое файла, удалить файл в каталоге, создать файл с тем же именем, записать в него старое содержимое + новое. Восстановить атрибуты,  дату и время по вкусу.
  5. От рута: получить доступ суперпользователя (например, на “рутованном” сервере) и внести изменения в read-only файл.
Гарантированно защитить read-only файл от изменений можно лишь при соблюдении следующих условий (всех до одного):
  1. На файл установлены атрибуты “только для чтения” (например, 400 или 440)
  2. На каталог, в котором размещен файл, установлены атрибуты “только для чтения” (например, 500 или 550)
  3. У хакера нет доступов по FTP (можно закрыть через .ftpaccess на запись или по IP) и SSH (отключить его)
  4. На хостинге запрещены все возможные варианты изменения владельца и атрибутов файла (chmod, chown, system, popen, shell_exec, passthru и т.п.)
  5. Сервер не взломан, у хакера нет доступа с правами суперпользователя (root)
Если хотя бы один пункт не выполнен, гарантировать защиту файла от модификаций нельзя.
Кстати, под Linux можно использовать расширенные атрибуты, установив на файл "readonly" командой chattr +i file.txt
Данный подход защиты файлов от модификаций используется в процедуре cms hardening ( "цементирование сайта" ), которую мы выполняем при установке защиты .
linux readonly revisium администрирование взлом защита модификация ревизиум
Alt text
«Опасное будущее» наступает очень быстро, поэтому мы решили еженедельно мониторить поток новостей. Cмотрите обзор на нашем Youtube канале.  

revisium

Блог компании "Ревизиум": лечение сайтов от вирусов и защита от взлома. Информационно-познавательные материалы из мира безопасности и защиты сайтов.