- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
В связи с несколькими взломами сайта за последнее время, у меня появились вопросы по предотвращению подобных ситуаций в дальнейшем.
1. На сервере стоит Apache ITK. В связи с этим, получается, что для каждого виртуального хоста выполнение скриптов происходит от имени пользователя, который этими скриптами владеет. То есть, если виртуальный хост создан пользователем admin123, то он же и является владельцем файлов. Это довольно таки плохо, так как залив на сайт скрипт, найдя уязвимость в CMS, можно изменять любые файлы системы. Даже если права на файлы выставлены так, чтобы запись не была разрешена. Как я понимаю, выход такой: создать ещё одного пользователя и сделать его владельцем всех папок и файлов. Таким образом, пользователь admin123 не сможет записывать или изменять ничего в файловой системе.
2. Существует ли какой-либо скрипт мониторинга файлов, который ежедневно будет проверять, не было ли изменений в файлах CMS (размер, дата изменения, новые файлы). Сравнивая их со значениями предыдущего дня. Таким образом, можно вовремя обнаруживать новые файлы и различные включения на сайте.
Наверное, лучше, если он будет написан не на PHP, чтобы быстрее работал (файлов довольно таки много). Хотя, я в этом не уверен.
Можно, чтобы скрипт проверки изменений был платный. Желательно, чтобы не был сделан для какой-то конкретной CMS.
Я нагуглил несколько разных скриптов, но хочется узнать мнение кого-то, кто уже пользуется подобным.
Спасибо!
Существует ли какой-либо скрипт мониторинга файлов!
Такой не знаю, но для этих задач мы используем mywebsitemonitor, он проверяет доступность сайтов и изменения кодов на странице. То есть мониторит все js, iframe, и так далее из веба.
В принципе о взломе и дописывании кодов узнаете сразу.Если что-то на странице изменилось - скрипт сразу шлёт уведомление.
Если скрипт заинтересовал и не нагуглите его, завтра могу поделиться, исходник на рабочем компе
выполнение скриптов происходит от имени пользователя, который этими скриптами владеет. То есть, если виртуальный хост создан пользователем admin123, то он же и является владельцем файлов.
а где тогда логика? если вы пользователя наделяете правами админа, то следственно надо разграничить классами, что он может делать, а что нет ...
это изначально продумывается, когда пишется ядро CMS, что б потом голова не болела в поисках
изменённых файлов, не понятно кем ...
Существует ли какой-либо скрипт мониторинга файлов
существует и здесь недавно предлагался... На Замок - сервис мониторинга сайта от взлома и хакеров
а где тогда логика? если вы пользователя наделяете правами админа, то следственно надо разграничить классами, что он может делать, а что нет ...
это изначально продумывается, когда пишется ядро CMS, что б потом голова не болела в поисках
изменённых файлов, не понятно кем ...
Я, наверное, не совсем понятно написал то, что имел в виду. Раньше на сервере апач исполнял php-скрипты используя пользователя apache. Как я понимаю, ему можно было запретить изменять файлы, просто изменив права (допустим, 777 на 644). Владельцем файлов при этом был admin123. После установки Apache ITK, php-скрипты исполняются от имени admin123. Он же (admin123) и владелец файлов. Таким образом, admin123 имеет полный доступ к файлам и папкам и изменение прав не даёт никаких результатов.
Этот вопрос никак не связан с CMS. Он связан с правильной настройкой прав на сервере. Я не хочу давать php-скриптам возможность вносить изменения в какие-либо файлы на данном хосте.
---------- Добавлено 13.03.2012 в 02:34 ----------
Такой не знаю, но для этих задач мы используем mywebsitemonitor, он проверяет доступность сайтов и изменения кодов на странице. То есть мониторит все js, iframe, и так далее из веба.
В принципе о взломе и дописывании кодов узнаете сразу.Если что-то на странице изменилось - скрипт сразу шлёт уведомление.
Если скрипт заинтересовал и не нагуглите его, завтра могу поделиться, исходник на рабочем компе
Спасибо, но подобный сервис я уже использую. Он действительно помогает. Но я не хочу ограничиваться на этом.
Но я не хочу ограничиваться на этом.
как я понял, речь о VPS и распределение прав между пользователями? так?
существует и здесь недавно предлагался...
Этот сервис уже используется. Несколько дней назад именно он помог обнаружить редирект. Кроме него, я ищу ещё и серверный скрипт для мониторинга файлов. Он не будет делать мониторинг страниц сайта. Он должен проверять изменения самих файлов на сервере.
---------- Добавлено 13.03.2012 в 02:38 ----------
как я понял, речь о VPS и распределение прав между пользователями? так?
Да, выделенный сервер. Вопрос №1 именно о правах пользователей. Вопрос №2 - о скрипте мониторинга файлов внутри серевера.
Вопрос №1 именно о правах пользователей.
На этот вопрос вы как бы сами уже ответили. Если владелец файлов будет отличаться от пользователя от которого выполняются скрипты и права на файлы будут 644, то никто туда записать ничего не сможет. Только что проверил даже:)
Я не хочу давать php-скриптам возможность вносить изменения в какие-либо файлы на данном хосте.
Для некоторых файлов требуется возможность изменения их скриптами, такие как кэш, настройки если хранятся не в бд, ну и прочее. А так да, распределите систему прав на статических скриптах, не знаю но у меня на шареде вполне работает, не позволяя отредактировать файлы другим владельцам (кроме с фтп).
Но вы не указали самого главного, свою кмс. И я наверняка угадаю, если скажу что это ДЛЕ (или хостится на одном акке) (в чуть меньших случаях ВП), не видавший обновления года два, без критических патчей безопасности и возможно даже нулленая.
На этот вопрос вы как бы сами уже ответили. Если владелец файлов будет отличаться от пользователя от которого выполняются скрипты и права на файлы будут 644, то никто туда записать ничего не сможет. Только что проверил даже:)
....конечно не сможет🙅
На этот вопрос вы как бы сами уже ответили. Если владелец файлов будет отличаться от пользователя от которого выполняются скрипты и права на файлы будут 644, то никто туда записать ничего не сможет. Только что проверил даже
Да, я понимаю. Значит, это правильный путь (создать ещё одного пользователя и сделать его владельцем файлов)? Или правильнее настроить Apache ITK как-то иначе?
---------- Добавлено 13.03.2012 в 03:05 ----------
Для некоторых файлов требуется возможность изменения их скриптами, такие как кэш, настройки если хранятся не в бд, ну и прочее. А так да, распределите систему прав на статических скриптах, не знаю но у меня на шареде вполне работает, не позволяя отредактировать файлы другим владельцам (кроме с фтп).
Для тех папок, где нужно иметь возможность добавлять и изменять файлы, будет оставлен текущий владелец.
---------- Добавлено 13.03.2012 в 03:09 ----------
Но вы не указали самого главного, свою кмс. И я наверняка угадаю, если скажу что это ДЛЕ (или хостится на одном акке) (в чуть меньших случаях ВП), не видавший обновления года два, без критических патчей безопасности и возможно даже нулленая.
Название CMS не имеет никакого значения. Оба вопроса никоим образом не касаются CMS. Стояли две платные не нуленные CMS (одна для сайта, одна для форума). Это были не ДЛЕ и не ВП. Взломали потому, что я не обновлял ни одну из них в течение долгого времени (да, знаю, что я идиот :)).