Во-первых, мои соболезнования по поводу необходимости иметь дело с чем-то вроде этого. Но вы можете очистить это. Во-первых, мне просто нужно решить эту проблему:
Я подозреваю, что это произошло, потому что я не использовал ключ SSH со своим паролем.
99% уверены, что это не так. Практически каждый компромисс веб-сервера, с которым я лично сталкивался (и исправлял) за более чем 20-летний опыт работы, связан с недостатками на уровне приложений, а не с тем, что связано с SSH или SFTP. Фактически, большинство веб-разработчиков / администраторов никогда не будут иметь дело с компромиссами уровня SSH / SFTP; Недостатки во фронтальном коде являются основной отправной точкой для многих вредоносных программ и необоснованных вторжений в общедоступные веб-системы.
И в вашем случае вы заявляете следующее:
Это была Ubuntu 14, и там было 6 виртуальных хостов Apache. Все были живы.
Одним из моих сайтов была установка WordPress с парой плагинов.
На другом сайте был код API Карт Google.
Я предполагаю, что - если вы не будете в курсе обновлений / патчей WordPress - ваши установки WordPress были уязвимы. И не только ядро WordPress, но и плагины.
Резервное копирование существующей кодовой базы, базы данных и конфигов.
Самое первое, что я хотел бы сделать, это нейтрализовать виртуальные хосты Apache, установив index.php надписью «Down for Maintenance» в каждом из корневых индексов этих сайтов. Я также сделал бы копию каждой установки виртуального хоста через архив TAR/Gzip и загрузил бы ее для потенциальной экспертизы. Это должно быть сделано для всех виртуальных серверов Apache, включая дампы баз данных MySQL, а также соответствующие файлы конфигурации.
Проверьте каталог /tmp/ наличие признаков заражения; взорвать его, если это будет необходимо.
Следующее, что я бы порекомендовал вам сделать, это создать дамп и заново создать каталог /tmp/ на сервере. Причина в том, что многие заражения вредоносным ПО на веб-серверах Linux помещают значительную часть своей полезной нагрузки в каталог /tmp/ . Я углублюсь в этом ответе здесь, но он сводится к следующему.
Итак, во-первых, посмотрите в каталог /tmp/ и посмотрите, есть ли там что-то, чего не должно быть. 9 раз из 10 вредоносных программ в системах Linux смогут установить себя в /tmp/ .
Если вы не уверены, что должно / не должно быть в /tmp/ есть простая, но экстремальная вещь, которую вы можете сделать, чтобы убрать плохие вещи. Просто запустите это онлайн в командной строке:
rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp
Или выполните каждую команду в отдельности, как это:
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
Затем перезагрузите сервер, чтобы посмотреть, все ли прояснится. Если это так, поздравляю! Но вы еще не вышли из леса, поскольку, что бы ни вызвало первоначальная система, все еще может проникнуть в вашу систему, это лишь вопрос времени, когда они снова заразят вас. Это означает, что это устраняет беспорядок, вызванный слабостью вашей системы, но вам нужно выяснить, что это за слабое место, и укрепить его.
Проверки уязвимости Bash «Shellshock».
И в этом другом ответе я даю советы о том, как проверить уязвимость bash «shellshock». Этот сайт предоставляет хорошие инструменты тестирования, чтобы увидеть, уязвим ли ваш сервер для эксплойтов bash . Честно говоря, это была одна из наиболее распространенных дыр в безопасности, которые мне приходилось исправлять с момента ее обнаружения. Так что есть большая вероятность, что это может быть слабым местом и на сервере. Что касается того, как исправить уязвимости bash если они найдены, см. Раздел ниже о том, как обновить / исправить все компоненты уровня ОС. Сделайте это, и bash должен быть обновлен / исправлен.
Обновите / исправьте все компоненты уровня ОС.
Сейчас это может показаться пугающим, но реальность такова, что исправления безопасности выпускаются постоянно для систем Linux. И если вы используете стандартизированную установку Linux, такую как Ubuntu или CentOS, вы можете просто запустить обновление / обновление через установщик вашего пакета следующим образом. На Ubuntu просто сделайте это:
sudo apt-get update
sudo apt-get upgrade
Теперь, если вы не обновляли систему в течение некоторого времени, вы можете увидеть огромное количество исправлений и обновлений, с которыми нужно иметь дело. Не паникуйте! Это нормально. Просто запустите update и upgrade и ждите. Может потребоваться перезагрузка после этого, но когда это будет сделано, ваша основная ОС должна быть полностью исправлена и обновлена.
Оцените кодовую базу ваших систем кодирования виртуальных серверов Apache; WordPress и Google API.
Готовьтесь: это самая уродливая часть. Вам следует скачать и оценить кодовую базу, которая была потенциально заражена. Надеемся, что только один или два сайта были взломаны. Как это сделать, является своеобразным для каждой установки, но, как правило, вы должны загрузить каждый сайт в среду разработки, обновить ядро WordPress, обновить плагины, проверить, все ли работает нормально, а затем считать этот код чистым. / стабильный.
Теперь я значительно упростил этот шаг. Но реальность такова, что даже после внесения исправлений и обновлений в ядре WordPress может остаться вредоносный код. Итак, другая вещь, которую вы можете сделать, это перестроить каждый сайт WordPress с нуля. Сохраните базы данных, шаблоны и в основном перестройте сайт из нового, чистого ядра WordPress.
Да, это звучит как большая работа, но если у вас так много виртуальных серверов с разными кодовыми базами на них, выбора нет.
Посмертный совет.
Это работает не для всех, но я скажу так: резервные копии и, возможно, даже GitHub-репозиторий для чистой базы кода - это способ убрать путаницу без грязного последнего шага «оценки», который я сделал выше.
Что я делаю, так это запускаю обычные дампы MySQL на любом сайте, где я работаю, и я проверяю, есть ли чистая базовая кодовая база в GitHub. Затем, если происходит заражение вредоносным ПО, я могу копаться в резервных копиях MySQL и даже повторно развертывать чистый код из GitHub, чтобы убедиться, что кодовая база чистая. А если сам сервер просто пропал мимо веры? Что ж, просто дамп инфицированной системы, перестройте новую систему Linux, разверните код, импортируйте базы данных, настройте конфигурации и называйте это день.
Помните, что 99% всех сайтов - это просто базы данных, кодовая база и набор конфигов. Если у вас есть какой-то чистый способ «заморозить» или сделать резервную копию неинфицированного кода и резервную копию баз данных MySQL, то все, что вам нужно сделать, - это заняться настройкой. Что является незначительной болью по сравнению с очисткой кода с нуля.
