Старые фокусы на&nb p;новый лад

Страшный сон любого веб-программиста: взломанный сайт. И ладно если просто заглавную страничку подменили (так называемый дефейс), а если втихую дописали ссылки на вирусы или вредоносные скрипты? Это уже не просто неприятно, но и чревато подпорченной репутацией не только сайта, но и компании. Постоянно контролировать сайт — это, несомненно, выход. Но «постоянно» — это насколько часто?

 

 

Раз в день? Несколько раз в час? За час (а тем более за сутки) модифицированный сайт может дискредитировать себя и своего владельца напрочь. Что можно сделать?

А сделать можно многое. Например, если на время избавиться от гипнотической приставки «веб» в слове «веб-программирование» и сосредоточиться непосредственно на оставшемся термине, можно припомнить старые трюки программ доинтернетовской эпохи. Те программы, которым было принципиально важно сохранить целостность своего кода и данных, использовали контроль за ними, а иногда и восстанавливали их при обнаружении отклонений. Эти трюки вполне реально перенять и программам, написанным на каком-либо языке веб-программирования.

Борьбу со злонамеренным пользователем вашего сайта можно разделить на следующие этапы:

• превентивные меры: запутывание злонамеренного пользователя;
• отслеживание изменений исполняемого кода;
• отслеживание несанкционированного изменения данных;
• восстановление измененных кода и данных.

Как видите, в принципе своем алгоритм взят полностью из программ, написанных на старых добрых офлайновых средствах разработки.

Превентивные меры: запутывание злонамеренного пользователя

Если у вас нет файлов, на которые может позариться вирус, то радоваться рано. Вполне возможен вариант, что вредоносный код, не найдя обычной среды для размножения, воспользуется первым попавшимся под руку материалом

Эти меры подразумевают под собой, к примеру, подмену взламываемого кода или базы данных. Например, есть такие вирусы, которые заражают часто встречающиеся файлы (index.*, main.*, login.* и так далее) на хостинге. Если у вас таких файлов нет и начальная страница вашего сайта вовсе не index.html, а, к примеру, first_page.html, то радоваться рано. Вполне возможен вариант, что вирус, не найдя обычной среды для размножения, воспользуется первым попавшимся под руку материалом. Лучше «успокоить» его, создав файлы-пустышки index.php или index.htm, пусть селится в них сколько угодно. А для исключения ситуации случайного заражения нелишне будет обезопасить пользователя с помощью mod_rewrite в файле .htaccess:

RewriteRule index.php first_page.html

или с помощью DirectoryIndex:

DirectoryIndex first_page.html

Базу данных тоже можно продублировать муляжом — потратив силы на взлом этой отвлекающей базы, у злоумышленника вполне может не остаться времени и запала на остальное.

Отслеживание изменений исполняемого кода

Этот пункт подразумевает под собой проверку по каким-либо параметрам скриптов, отправляемых на исполнение. Например, по времени создания, размеру файла или его контрольной сумме. Однако при большой нагрузке на сервер контролировать каждый запускаемый файл довольно ресурсоемко, особенно прожорлива проверка контрольной суммы (MD5, SHA1). Поэтому можно прибегнуть к контролю выборочному или по расписанию — допустим, проверять все скрипты на вшивость несколько раз в час или ограничиться проверкой только жизненно важных файлов. На PHP контроль можно осуществить с помощью следующих функций:

• getlastmod — возвращает время последней модификации текущего файла. Синтаксис:
  $time=getlastmod();

• filemtime — получает время последней модификации заданного файла. Синтаксис:
  $time=filemtime($filename);

• md5_file — вычисляет MD5-хеш заданного файла (32-значное шестнадцатеричное число). Синтаксис:
  $md5_hash=md5_file($filename);

• sha1_file — вычисляет SHA1-хеш заданного файла (40-значное шестнадцатеричное число). Синтаксис:
  $sha1_hash=sha1_file($filename);

Отслеживание несанкционированного изменения данных

Кроме хранения непосредственно самих данных (новостей, комментариев, статей), возможно хранить и хеш каждой записи отдельно. Если у записи вычисленный хеш не соответствует эталонному — пора срочно принимать меры.

Восстановление измененных кода и данных

После того как проверкой замечено изменение кода или данных злонамеренным пользователем, можно либо известить программиста (например, отправив сообщение электронной почты), либо взяться за исправление автоматически. Оригинальным способом представляется получение неповрежденных данных и кода с другого принадлежащего вам сайта посредством специального скрипта. В этом случае, для того чтобы парализовать работу одного сайта, будет необходимо получить доступ к двум, а это несколько сложнее. Простой пример получения файлов в исходном виде с другого сервера:

$recover=file_get_contents("/redir.php?url=server2.com%2Frecover1%2Fgetcontent.php%3Fid%3Dindex%26code%3D0F4A77C1%26%2334%3B%29%3B%3Cbr%3E $byte_count=file_put_contents("index.php", $recover);

getcontent.php на сервере server2.com должен выдать index.php в исходном виде. Параметр id конкретизирует, какой именно файл мы хотим получить, а параметр code — мера предосторожности, пароль, предотвращающий получение исходников третьими лицами. Естественно, во избежание получения кода посторонними надо защитить канал передачи исходников от сервера-«донора» пострадавшему серверу как можно лучше: шифровать передаваемое, использовать контроль по IP-адресу и так далее. Также можно хранить резервную копию и «рядом» в зашифрованном виде, тут реализация ограничивается только свободным местом на диске и вашей фантазией.

Таким образом, возложив функции восстановления поврежденного контента и скриптов на сам сайт (или два-три сайта) и уподобив их возрождающейся из любого (правда, с работающим Cron) пепла птице Феникс, можно вздохнуть несколько свободнее.

Ссылки по теме

• О CRC в «Википедии»
• О хешировании в «Википедии»
• О дефейсе в «Википедии»

Статья получена: hostinfo.ru

загрузка...