Почему 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 ( "цементирование сайта" ), которую мы выполняем при установке защиты .