YuriyB,

Кажется, вы не совсем понимаете ситуацию. Сам по себе код на яваскрипте обычно не содержит вирусов, но содержит ссылку, где эту дрянь можно получить. Способов проникновения левого кода на сайт не так уж и много. В большинстве случаев код в файлы сайта попадает по фтп. Троянов-тырилок логинов/паролей "на лету" и из стандартных мест хранения не так уж мало. В основном, они работают под виндой и не всегда сразу обнаруживаются антивирусами. Иногда код попадает через дыры в движке (не скажу конкретно за джумлу, но для самописных движков такой вариант имеет место быть).

По поводу 100% надежной защиты есть только один вариант - отключить сервер от сети [сарказм]. А вообще, принимайте меры чтоб на клиентских компьютерах занимались работой, а не цепляли троянов по интернетам. Пароли, конечно, следует поменять. Если предоставляете доступ третим лицам, ограничивайте их зону доступа по максимуму. Отдельные фтп-аккаунты этому поспособствуют. Кроме того, упростит процедуру поиска утечки (в логах будет видно, от какого имени правили файлы).

А дебиан-апач-пхп тут практически ни при чем. Если только все настолько криво настроено, что безопасность сервера опущена ниже плинтуса (например, рутовый вход без пароля).

Dimitry SibiryakovYuriyBну какие меры можно принять ?
тем более человек клиент
Если вы предоставляете услуги хостинга, то в договоре должна быть прописана
ответственность клиента за размещение вредоносного кода. Вплоть до расторжения договора и
удаления всех файлов.ИМХО удаление файлов - это какая то слишком жестокая мера. Блокировка вебсервера на аккаунте "до устранения" - это еще куда ни шло. Да и то, думаю, перебор.

На самом деле, в данной ситуации целиком и полностью виновен клиент. Именно он (а не хостер и никто другой) передал или, сам того не осознавая, создал условия для передачи пароля третьим лицам. Хостер не может никаким образом контролировать действия пользователя в этом плане. В договоре ответственность клиента за сохранность паролей должна быть четко и однозначно прописана. Каким бы долбодятлом ни был клиент, права на ошибку у него отбирать не следует. Но ответственность за эти ошибки должна быть возложена на него.


YuriyBкак можно блокировать такие вещи или быстро их определять
на стороне сервера ?Ограничение фтп и шелл доступа по айпи. С возможностью правки самим клиентом через панель управления. Клиенты будут первое время "очень довольны" таким нововведением. Однако, если объяснить для чего оно надо, возможно, недовольных останется не слишком много. Это одно.

Проверка всех подряд файлов антивирусом с последующим уведомлением клиента неутешительными результатами проверки. Ясен пень, сие запускать в часы наименьшей нагрузки. При хорошем раскладе (клиент отреагировал быстро, пока есть живая резервная копия) восстановление будет достаточно простым. Впрочем, эту идею можно попытаться развить в сторону автоматизации выковыривания неповрежденного файла из бекапа.

Dimitry Sibiryakovmod_substitute и удалять из тела всё от "<script type="text/javascript"" до "</script>".Сарказм? ;-)

Из бесплатных - ClamAV.
Какой из платных - это сами уж решите :)
Не уверен, но возможно есть вариант прикрутить антивирь непосредственно к фтп.

Однако, у любого антивиря могут быть и ложные срабатывания, и пропуски. Это следует иметь в виду. Тот же clamav пару дней может находить угрозу в совершенно чистых файлах.

Уязвимости браузера, человеческий фактор

nsclЭто позволить клиенту вовремя понять, что сайт вредоносно пропатчили без его ведома.Или задолбает сообщениями по каждой легальной правке.