Если вывести текст запроса ($sql) на каждом из хостингов, будут ли между ними различия?
Иными словами, что на каждом хостинге выводится на var_dump($sql) ?
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 и доменного имени чем-то не угодившего сайта. Закрыть его, вероятнее всего, не закроют, но крови владельцам выпьют изрядно.
