А самое интересное не написали — как модуль попадает на сервер?
Очевидно что раз добавляются модули apache и вносятся изменения в конфиг, то для этого нужен root-доступ, то есть путём кражи данных пользователей. Либо, как вариант, exploit для серверного софта, того же apache + повышение привилегий.
Скачать модуль ускорения apache бесплатно без регистрации и смс здесь
Прочитавшие этот комментарий делятся на два типа: кликнувшие по слову здесь и некликнувшие.
Ещё есть те, кто навел мышь. чтобы узнать куда ведёт ссылка
Они относятся к некликнувшим.
НЛО прилетело и оставило эту надпись здесь.
Не хотевшим, а интересующимися. К тому-же весьма проблематично словить виндовый или линуксовый эксплойт под OS/2. ;)
НЛО прилетело и оставило эту надпись здесь.
Да, да. Мы вот сидим и думаем, нужен-ли отдельных хаб про OS/2 — eComStation — osFree на хабре или ну его нафиг?
ключ по ssh подобрали
«Запусти апач от рута! Это модно! Это круто!»
Прав же много никогда не бывает.
Есть несколько простых советов, которыми, к сожалению, не все пользуются, поэтому у злоумышленников и есть возможность устанавливать вредоносные модули Apache.

Нужно очень тщательно беречь свои реквизиты для FTP- и SSH-доступа, а также доступа к системам настройки веб-серверов:
1) предоставлять root-доступ только тем, кому доверяете;
2) пароль должен быть по-настоящему сложным, его нужно регулярно менять и нельзя отправлять в открытом виде;
3) если сервер настраивается с компьютера или устройства, на котором Microsoft Windows, MacOS, Android – нужно, чтобы на нём обязательно были антивирус и firewall;
4) необходимо, чтобы соединение было зашифрованным, нужно обращать внимание на валидность сертификатов и сообщения об ошибках, связанных с ними, с осторожностью пользоваться прокси транспортного уровня.
И это все оказывается бесполезным в результате не обновленной Убунты с php-cgi и дырявым ядром) После чего приходит ботнет, через пару дней приходит ботовод, получает рут и делает зло.
blog.imperva.com/2014/03/threat-advisory-php-cgi-at-your-command.html

Это я к тому, что вариантов проникновения много, и Ваши советы не полные и не учитывают наиболее частые сценарии.

Далее: ваши советы можно и нужно улучшить.

1) Не представлять рут доступ. Если нужно, то только через SUDO.
2) Никакой аутентификации по паролям. Ключи.

ФТП — зло, противоречит пункту 4, только если не VPN или FTPS. И то, зачем FTP, если есть SSH?
Плюс ко всему, часто заражение начинается с эксплуатации уязвимости в скриптах какой-нибудь популярной CMS. Далее осуществляется загрузка на сервер php shell'а, а там уже как получится.
В этой связи, необходимо следить за актуальностью версий используемых CMS. Если по каким-то причинам обновить CMS до актуальной версии не представляется возможным, как показывает практика, довольно эффективной мерой является максимальное ограничение прав на запись в поддиректориях таких сайтов (хотя, это, конечно, не панацея).
Более полное описание, как не допустить заражения сайта в общем случае, тоже есть, help.yandex.ru/webmaster/security/protecting-site.xml. Но даже если самые простые меры выполнять, не вызывающие больших неудобств и не требующие глубоких технических знаний, то вероятность, что сайт попадёт под автоматизированное, массовое заражение, уже существенно снижается. К сожалению, не все даже это делают.
Все равно это советы для «широкой, неподготовленной аудитории кастомеров, которых не надо загружать излишней и 'сложной' информацией». Но вообщем это сойдет для определённой целевой аудитории.
5) На продакшн-серверах отключить SSH доступ на интерфейсах, смотрящих «в мир». Если сервер у провайдера, тогда SSH для его управления прикручивается только к интерфейсам за VPN.
6) Отказаться от FTP, перейдя на FTPS, SFTP, SCP.

В идеале на продакшн-сервере нет VPN сервера, есть только VPN клиент. Т.е. нет приложения, слушающего входящие порты. В данном случае VPN клиет подключается к VPN серверу, инициируя соединение и создавая защищённый канал. По этому каналу можно ходить на SSH, SFTP, etc. В результате сканеры портов на исследуемом сервере будут видеть со стороны мира открытым только 80 HTTP порт. Ничего сверхзаурядного. Просто и надёжно.
Обычно такие посты читаем от ESET, но никак не от Yandex, было очень интересно.
Роботы яндекса начали кушать swf файлы? Иначе как они определяют какая флешка хорошая а какая плохая?
Какая разница, какой объект проверять? Сигнатурному анализатору все равно.
Иногда вредоносный код в графические объекты инжектят (правда, это серверный вредоносный код, но тем не менее). Таким образом, все что отдает веб-сервер имеет смысл проверять.
Ну тут вы ошибаетесь. А если у меня на сайте 100 фильмов по 50 гигов? робот тоже регулярно будет их проверять? Я абсолютно уверен что робот кушает только определенные файлы.
Очевидно, есть ограничение на размер проверяемого объекта (в т.ч это могут быть ограничения движка). Но исключать объекты из проверки только по типу было бы крайне неэффективно в современных условиях.
Этот код определял, какие программы установлены у пользователя

Помимо того, что доступ к navigator.plugins позволяет выполнять такие вот скрипты, по нему можно составить отпечаток, увеличивающий уникальность данного браузера в несколько раз. Сколько не искал, как можно ограничить доступ к списку плагинов из JS в различных браузерах — так и не нашел.
НЛО прилетело и оставило эту надпись здесь.
Хром даже при отключении плагинов в настройках продолжает выдавать их список скриптам на странице. Это смешно.

С другой стороны, сразу виден уровень современного разработчика. «Какой дурак будет отключать плагины? А JS? У нас половина браузера на нём написана, ха-ха-ха!»
А вот так заработало:

navigator.__defineGetter__("plugins", function() { return []; });

Надо сделать расширение.
Обходится с помощью delete navigator.plugins;
NB: Весь вредоносный код в посте дан в виде скриншотов для того, чтобы роботы не сочли и эту страницу заражённой.


Странный у вас алгоритм, не различающий чистый HTML-код от экранированного.

Получается, если я перепечатаю то, что на скриншоте и вставлю этот код на страницу какого-нибудь сайта, который корректно заменит символы < и > на соответствующие чаркоды, то при следующем индексировании данной страницы роботом Яндекса, тот посчитает её вредоносной?

Забавно :)
Интернет обходится не только роботами Яндекса.
Думаю, что чаркоды тут особой роли не играют. Если бы я писал такого рода парсер, то уделял внимание только словам и словосочетаниям с определенными характеристиками, и «мусор» типа %7С или & nbsp не учитывал бы.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.