Что можно придумать в общем случае от установки вредоносного кода на сайты клиентов типа сапы? Или Как защититься от недобросовестных разработчиков?

Question

[p4s8x]

Предыстория такая: обратился клиент с сообщением — на его сайте «какие-то ссылки» внизу страницы. Ссылки как оказались вели на клубничку и принадлежат нескольким сапам. Начали один за другим проверять сайты клиентов и нашли еще несколько.

Как временное решение — повесили на систему мониторинга скрипт, который бегает по всем сайтам и проверяет на главной странице наличие ссылок, похожих на сапы и прочие.

Теоретически — кому сломать руку мы уже догадываемся, но хочется продумать решение, если и не запретить, то хотя бы как-то вовремя обнаруживать установку такого кода.

Прорабатывается идея — на уровне apache/nginx проверять отдаваемый хтмл по шаблону.

Кроме регулярной смены пароля и прочих всем известных правил соблюдения безопасности, какие решение используются в Ваших компаниях? Есть ли подобный опыт?

Answer 1

[a_andry]

Можно попробовать через incron отслеживать изменения в файлах.

Answer 2

[egorinsk]

1) не сотрудничать с кем попало.
2) после того, как разработчик сделал изменения, можно сравнить исходный код и измененный и посмотреть, нет ли там чего подозретельного.

Answer 3

[Илья Плотников]

Явно не такие костыли. Лучше отследить запросы, посылаемые сайтом наружу. Ссылки то откуда-то грузятся?

Answer 4

[Wott]

DVCS заодно и деплой на продакшн будет и с разработчиками будет проще

Answer 5

[Hint]

Приходится поддерживать большой сайт, написанный довольно давно другими разработчиками. Уже несколько раз находил шеллы и закрывал «засвеченные» дыры. Каждый раз поиск шеллов и очередной дыры происходил уже после того, как владелец ресурса нес убытки. В итоге, написал простой скрипт, проверяющий файлы по md5 и добавил его в cron (сначала был составлен каталог файлов, а теперь этот список обновляется при каждом найденном изменении). В случае изменения отправляется письмо на почту, поэтому не надо регулярно проверять логи вручную. Гора с плеч.
Скрипт лежит вне www директории.

Comments

[egorinsk]

Можно поместить сайт в CVS и делать diff для того, чтобы увидеть, что было изменено.

Ну и еще, раз у вас старый сайт, который дыряв и никто его чинить не хочет, стоит подумать об application firewall вроде mod_security — это такой модуль, который блокирует (и логгирует) запросы к сайту содержащий подозрительные слова типа '1=1 UNION SELECT' или '[script src'. mod_security, конечно, один большой костыль, но в вашем случае, это лучше, чем открытый всем хакерам сайт.

Answer 6

[Hungry_Hunter]

Конечно очень печально, что разработчики так некрасиво поступают.
Способы есть разные. Написать скрипт проверки даты всех файлов, размеров, содержимого.
Давно думал об этом, и придумал в свое время замечательный сервис, который мониторит все это дело на сайтах. И меньше чем за сутки спалит все эти сапы и прочую дрянь.
nazamok.com

Comments

[Hungry_Hunter]

Не совсем правильно выразился. Мониторит не изменение файлов скрипта, а сам html код каждой страницы удаленно на предмет появления ссылок, скриптов, ифреймов, воровства трафика.

Answer 7

[Сергей Соколов]

Подход зависит от того, как устроено: речь про ваш сервер с кучей сайтов и толпой левых девелоперов, или про сотни серверов разных клиентов, где у вас то просто FTP доступ, то SSH с рутом.

Политика может быть «с заморозкой»: сайт клиенту выкатили — код «заморозили», ни одного изменения быть не может, или мы снимаем с себя ответственность за вирусы. В таком случае можно хоть каждую полночь rsync'ом с вашего надёжного репозитария экспортить весь код сайта на рабочий серв. Или распаковывать архив с кодом, перезаписывая всё. Или проверять хэш файлов, и перезаписывать только при изменении.

Другой вариант для левых девелоперов: политика «всё через SVN». Ваш надёжный админ настраивает систему таким обрзаом, что каждый веб-проект имеет изолированную ветку или отдельное хранилище. Девелопер обкатывает всё на своем локальном тестоовом сервере, и выкатывает работающий код в хранилище. По расписанию, или по спец. ссылке код из репо копируется на продакшн сервер.
Таким образом у левого индуса нет возможности напрямую что-то исправить на рабочем сервере, минуя репо. И вы можете просто закрыть в нужный момент обновления на продакшн, а если понадобится открыть — сначала проверите, что за изменения внес ваш пакистанский гений.