Эм, и что этим постом вы хотели донести лично до меня? md5-сумма есть контрольная сумма, и что? Мне это прекрасно известно, я лишь стараюсь, что бы понятно было не только мне, о чем я говорю.
По поводу систем мониторинга сервера, уж простите, но это не только и не столько tripwire и где этот самый трип хранит данные - как-то все равно. Мониторинг сервера - это комплекс действий и задач по отслеживанию работы сервера, и в частности его ПО. А чем вы его будете выполнять, при помощи готового ПО, при помощи самописного, на java он будет, php или вообще bash-скриптами - вообще никакой разницы. Главное - его эффективность в предупреждении действий, о которых мы хотели бы знать.---------- Добавлено 04.10.2013 в 17:25 ----------Вон, Оптимизайка даже привел примеры ПО. Но это лишь одни из некоторых, тот же OSSEC я уже упоминал выше.
Если реферер у них у всех одинаковый, и при переходе передается - php код с их обработкой должен нормально отрабатывать. Я бы их еще куда-нибудь редиректил, вдруг кому эти юзеры интересны.
Если не отрабатывает, то или реферер отсутствует, либо бы неверно составили его определение. Если отстутствует - вы врядли что-то можете сделать, поскольку пользователи скорее всего разные, равно как и их IP/User-Agent, идентифицировать их будет сложно.
Но раз их вычисляют системы аналитики и счетчики - у них есть какой-то определенный параметр. Как вариант - создать php скрипт, который будет собирать совершенно все рефереры и куда-то их писать, в файлик или базу - на ваш вкус. После анализа данного файлика, и нахождении там этих рефереров - создать php обработку для них.
Скорее всего, вы либо неверно создали условие, либо ошибка в обработке условия.
Можете скинуть в личку этот кусок на php, я его гляну.
Смотря что поставить и как за ней следить. На самом деле эффективность этих систем на сайтах статического контента довольно высока. Основная задача - проверка md5 сумм файлов, например, и дат создания/последней правки. Эти проверки позволят узнать, что был отредактирован файл, который редактироваться в принципе не должен был.
Эти же системы мониторинга успешно применяются на серверах для отслеживания изменений в конфигурационных файлах, файлах системных и ключевых, о чем высылается уведомление.
PS: Мы конечно не ведем разговор о взломе сервера группировкой профессиональных хакеров, которые умеют замести следы. Мы говорим о потенциальных бот-вирях, дырах на дурака и прочих мелких неприятностях, которые могут настичь обычный сайт.
Присоединяюсь к тем, кто против древовидных. Действительно, не очень удобно и малоинформативно. Достаточно указания автора, или цитирования, если это ответ на предыдущее собщение.
Странная постановка задачи, если честно.
1) Сайт где расположен? Хостинг, выделенный сервер? Если хостинг, то, например, php-скрипт, например, позволяющий отслеживать изменения размеров или дат редактирования ключевых файлов с высылкой на email уведомлений по крону на стороне хостинга. Если сервер - то shell скрипты, собственные или любые сторонние, включая системы предупреждений вида OSSEC. Можно так же создать и подключить сторонний анализ сайта (проверка на валидность страницы; доступность сайта, домена; время и скорость отдачи контента и многое другое), как собственного производства, так и используя тонны сервисов в Интернете.
2) Постоянно хакают? Стоит пересмотреть логичность использования текущей CMS, либо произвести глубокую ревизию кода с устранением выявленных дыр и несостыковок при программировании. Если не часто - то пункт 1.
Собственно при уже готовом сайте эти 2 пункта и выполняются - ревизия или проверка надежности системы, и подключение мониторинга в зависимости от расположения сайта, и если уж вдруг хакнули - то да, исключительно постфактум решение проблемы и затыкание дыры.---------- Добавлено 04.10.2013 в 16:03 ----------
99% вебмастеров не отслеживают никак, разбираются с проблемой по факту ее обнаружения. А себя она так или иначе обнаружит. Вопрос только во времени ее обнаружении и последствиях. Чем важнее сайт - тем сильнее и быстрее последстия.
Если вы так по этому поводу переживаете - пункт 2 - ревизия системы с оценкой жизнеспособности системы и возможности ее хака.
Как сказали уже выше - без хотя бы альфы говорить не о чем. Без кода - не конструктивно. Я тоже могу расписывать как быстра моя CMS, но без реальной нагрузки и сторонней оценки - все это яйца выеденного не стоит. Не забывайте о "замыливании", когда вы видите только то, что уже видите.
На сколько помню, он выбирает первое попавшееся изображение с сайта. И обычно это лого. Если оно по коду идет первым. Если в коде оно не является первым, то значит в стилях css так прописано, что стиль с лого загружается позже других изображений с сайта. Ну, и вообще, на сколько мне помнится - картинки может перещелкивать сам юзер, жамкнувший на кнопку ВК.
Если я вообще правильно протелепатировал то, о чем вы спросили :)
Смотреть в сторону .htaccess, потом, если не найдется - в код сайта. Вирусни нет? На какие ссылки с гугла 301 кидает, не внешние случаем? Если на свои же внутренние - то htaccess. Если внешние - виряк. Убедитесь, что ваш хостер поддерживает и позволяет обрабатывать .htaccess файл.
Иногда так и должно быть, смотря какая CMS, как бы тайтл главной страницы - основной тайтл, к которому через разделитель добавляется перед ней тайтл подраздела или самой страницы. Часто так делают специально. Причем у вас вообще неплохо, бывает что сделан сначала тайтл основной, потом к нему страницы. Типа "Слон - Синие слоны", что неверно для ПС оптимизации.
Скорее всего проблема с кодировкой в связке "сайт-база данных". Посмотрите в какой кодировке создано то, и другое. Потому как английский в этом случае спокойно сохраняется, а вот UTF8 в CP1251 и наоборот - не засунуть.
Вариантов 2: или разбираться самому, или нанимать админа, который это будет делать за вас. Если сайты - не мегафинансовые, не супер скрипты на них под заказ, а обычные CMS + просто базы, то особых проблем со сторонним админом не должно быть. Риск конечно есть всегда, но он врядли будет велик.
Перечислять вам "базовые настройки" бесполезно, выделенный сервер - не 2 пункта меню у хостера. Это и безопасность самого сервера, и она заключается не только в том, что бы не ходить под рутом. Это защита ПО, ограничение его работы на определенных портах, разрешение стороннему пользователю видеть только нужные порты ПО, только нужные папки. Это и безопасность самого ПО, это и постоянный мониторинг логов сервера, свободного места и прочих мелочей. Своевременное обновление, умение найти проблему, локализовать, понимать, от чего возникла проблема, из-за хостера и ноды, или же она на вашем сервере.
Кроме того, важным является настройка и тюнинг ПО, такого как php/apache/nginx/базы данных. Так, например, в дефолтном значении апач может упасть и начать убивать процессы, даже при 2-5 пользователях на сайте одновременно. А в случаях высоконагруженных систем возможно нужно ставить допустим не просто Mysql, а что-нибудь вроде Percona DB.
В общем, распределение прав пользователям в случае с собственным сервером - это самый кончик верхушки айсберга. Свой сервер требует почти постоянного присутствия, настройки уведомлений и прочего счастья.
Если какие-то детали интересуют - можете в личку задавать вопросы, отвечу.
