CMS есть на множестве языков, не только на PHP.
Создание сайта из статических страниц вручную -занятие само по себе неблагодарное. Из вариантов, когда перенос статики в CMS относительно прост, могу посоветовать ikiwiki или TextPattern (второе для неподготовленного человека, IMO, проще).
В любом случае для ответа на первоначальный вопрос нужно больше информации - а именно, пояснить утверждение
.
Удачи!
Рад, что вам помогли всё решить.
Если будут сложности такого рода в следующий раз - буду рад помочь, пишите.
Правильно ли я понимаю, что не используете ни одну CMS? Тогда первый совет - начинайте использовать. Они для того и созданы, управлять контентом и экономить время.
Информация к размышлению.
1. Штатные средства инициировать действия после обновления файловой системы всегда под рукой; в случае Linux см. описание inotify. Так что сканировать каждые ннцать минут ничего не нужно, достаточно взвести монитор на изменение интересующих файлов.
2. Чтобы опознать, вредоносный то код или нет, нужна в общем случае неслабая эвристика. Типовые, всем известные вредоносные скрипты найти несложно, по сигнатурам, а вот что-то поумнее - придётся повозиться.
3. Системы обнаружения вторжений (с ходу: Snort) давно уже существуют, и если речь об этом - проще дописать модуль/новые правила к готовой системе, чем пытаться наново её изобрести "на коленке".
В общем, прежний совет - изучите для начала текущее состояние дел в отрасли. На полгода это вас точно займёт.
Просто к слову - а использовать функцию iconv() взамен написания её своими руками не надёжнее?
Насколько понимаю, код неполный - в том смысле, что приведён не полностью.
Две переменные, которым присваиваются имя файла (__FILE__) и номер строки в нём (__LINE__) могут быть нужны для раскодирования - поэтому декодирование .без них может ни к чему не привести.
Самый простой, многажды рекомендовавшийся способ - поставить до и после этой конструкции опознаваемые HTML комментарии, например <!-- footer BELOW --> ... <!-- footer ABOVE -->, затем открыть страницу в браузере, посмотреть, что выводится между комментариями, вставить в явном виде безобидную часть, а кодированный кусок весь выбросить.
По уму, стоит избегать шаблонов с такими вставками вообще, чтобы не подцепить в один прекрасный день через них что-нибудь небезобидное.
Возможно, удобнее использовать Location:
<Location ~ "/urlregexp"> Order Allow,Deny Allow from all Deny from <ipranges list> </Location>
где urlregexp определяет адреса, для которых действует запрет.
Может оказаться, что имеет смысл установить некую переменную (SetEnvIf), если IP в списке запрещённых, тогда использовать конструкцию вида
<Location ~ "/urlregexp"> Order Allow,Deny Allow from all Deny from env=ip_is_banned </Location>
Кстати, откуда берётся соотнесение IP и страны? GeoIP или аналог?
Проблема обеспечения безопасности не сводится к перехвату возможности стянуть FTP-данные и поиску внедрённого кода. Поэтому для начала простой совет изучить состояние дел в этой области, не зря же в ней пасутся большими стадами очень крупные компании.
И не забывать, что главная проблема любой службы информационной безопасности всегда сидит перед монитором.
В ситуации, когда неподконтрольный фактор, на котором легко можно сыграть, влияет на репутацию сайта в ПС, можно только посоветовать не принимать всё близко к сердцу, ибо пути Яндекса неисповедимы.
Примерно то же, что заказ спам-рассылки с указанием настоящих email и доменного имени чем-то не угодившего сайта. Закрыть его, вероятнее всего, не закроют, но крови владельцам выпьют изрядно.
Думаю, тут ещё нужно уточнить, на каком двигателе это всё работает. Лучше всего, если двигатель не прописывает нигде (в БД или ином месте), к какому конкретно домену привязан сайт.
Тогда задача сильно упрощается - простая синхронизация файлов и состояния БД между двумя (или более) сайтами. Сам решил такую задачу в своё время, чтобы всегда были под рукой идентичные реплики сайтов на разных хостингах: при сбое или слишком долгой недоступности основного для переключения на резерв достаточно сменить DNS-записи.
