- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
тем кому безопасность нужна уже заказали услуги администрирования, а тем кому безопасность "не нужна"ваши старания и не заметят.
Они просто пока не понимают, что эта "безопасность" им нужна, но нужна всем (а давайте это все-таки не называть безопасностью)
Им просто хочется где-то держать свои сайты, и так, чтобы они всегда хорошо работали, защищены от взломов, спамов и их не нужно было обновлять.
Такое почему-то не предоставляете. А все о мощностях каких-то.
А вы и покупаете мощности у "хостера", а не сайт.
Кто делал Вам сайт с тем и надо вести диалог если он дрявый.
У "хостера" в большинстве случаев все работает как часики, скрипты выполняются, база данных не падает, ПО настроено должным образом для корректной работы.
Если клиент не хочет заниматься своим сайтом в направлении безопасности (его и только его кода, который он сам написал - установил - заказал), то им тем более не захочет и не будет заниматься и хостер.
Что-то вы все усложняете антивирусами.
Берем старый добрый .htaccess
<FilesMatch "\.(inc|php|php3|php4|php44|php5|php52|php53|php54|php55|php56|phtml)$">
Deny from all
</FilesMatch>
Пишите скрипт на детектинг всяких джумл, вордпрессов и т.д. у них всех структура типичная, это не сложно сделать. Далее ищем папки с небезопасными правами доступа и от куда не выполняется php-код (к примеру в жумлах это: tmp, images, modules, plugins и т.д.), и помещаете туда .htaccess с содержимым приведенным выше.
Profit.
В большей части случаев помогает. Либо же приучать клиентов защищать свои сайты вот таким образом.
Кто-нибудь подскажет толковый антивирус аля малдет?
Их не бывает.
А вы и покупаете мощности у "хостера", а не сайт.
Услугу по размещению сайта, а не мощности.
Кто-нибудь подскажет толковый антивирус аля малдет?
Таких не бывает. Невозможно со 100% вероятностью определить зловредный скрипт или нет. Функции PHP, которые используются в зловредных скриптах (eval, system, base64_decode и прочие), также используются и в популярных CMS. Либо могут быть применены в стольких вариациях, что ни один антивирус не поймет, что это плохой код: http://habrahabr.ru/post/193986/ (даже до такого доходит).
Моё мнение таково: клиент занимается безопасностью своих сайтов, хостер занимается безопасностью сервера (например, чтобы клиент не мог сломать сайт соседа по серверу).
Возможно я менее компетентен в выражениях.
Но по моему, наоборот. Мощности, это может быть VPS/Shared да что угодно, туда может входить (канал/ресурсы сервера)
А размещает сайт уже непосредственно администратор сайта или программист. Соответственно он эти услуги и оказывает.
Могу ошибаться, буду рад если поправят.
По нашей проктике - массовый хостинг не способен решить эту проблему.
Это решается специализацией (по сути SaaS) когда хостер затачивает хостинг под определенную CMS и следит за ее обновлением и состоянием сервера имеент с точки зрения работы этой CMS.
А еще можно FTP запретить - гарантированно 95% с вирусами решится.
Всем привет.
С позиции хостера разборки по взломаным сайтам и разгребание последствий давно начали утомлять.
Поставили антивирус, который шлет уведомления клиентам и убирает в карантин то, что можно убрать - ситуацию улучшило, но не решило полностью - детектит не все, и часто на него забивают.
mod_security не панацея, дает многовато ложных срабатываний.
Основное с чем приходится бороться - заливка шеллов, спамеров, фишинг, дефейс, исх. ддос и брутфорс.
Исходя из этого, видимо, следует предотвратить запуск скриптов неизвестного происхождения.
Что приходит в голову - отдельный листинг доверенных скриптов, либо особая организация прав доступа.
Естественно, в приоритете охранение работоспособности сайтов и минимизация дополнительной нагрузки на сервер. В частности, есть вопросы по кешу, где постоянно происходит ротация исполняемых скриптов.
Хотелось бы услышать мнения коллег этим и другим вариантам защиты 🍻
В дополнение к тому, что вы написали:
1. Крутите антивирус не на ноде с клиентами, а на бекапном сервере (вы же делаете бекапы?)
2. Если один антивирус не находит много, сканируйте двумя (тот же кламав много не находит)
3. Используйте базу гугла по плохим сайтам, проверяйте домены, припаркованные на ваших серверах на наличие в блеклистах
4. используйте данные по попыткам скана/взлома централизованно (например, лейте все в эластиксерч) и разносите общие правила по всем серверам
5. сканируйте в риалтайме антивирусом файлы, передаваемые POSTом и загружаемые по FTP
Ну, и еще можно до бесконечности реализовывать. Главное не забывать про соотношение затрат на поддержку без того или иного инструмента и на внедрение этого инструмента.
Что-то вы все усложняете антивирусами.
Берем старый добрый .htaccess
Пишите скрипт на детектинг всяких джумл, вордпрессов и т.д. у них всех структура типичная, это не сложно сделать. Далее ищем папки с небезопасными правами доступа и от куда не выполняется php-код (к примеру в жумлах это: tmp, images, modules, plugins и т.д.), и помещаете туда .htaccess с содержимым приведенным выше.
Profit.
В большей части случаев помогает. Либо же приучать клиентов защищать свои сайты вот таким образом.
А по какому такому праву можно вставлять свой htpaccess в сайт клиента без его разрешения?
вообщем то не панацея но не плохое решение Suricata в режиме ips, защита от более чем 16к уязвимостей в режиме реального времени