Сегодня DigitalOcean сообщил мне, что мой Droplet там был отключен из-за DDoS-атаки.
Они попросили меня провести расследование и выяснить причину.
Это был Ubuntu 14, и у меня там было 6 Apache VirtualHosts. Все были живы.
Один из моих сайтов представлял собой установку WordPress с парой плагинов.
На другом сайте был код API Google Карт.
В остальных был только мой оригинальный код.
Я еще не вошел на сервер. Как только я это сделаю, как правильно найти программное обеспечение, вызывающее это?
Подозреваю, это произошло из-за того, что я не использовал SSH-ключ вместе со своим паролем.
решение1
Во-первых, мои соболезнования, что пришлось иметь дело с чем-то вроде этого. Но вы можете это убрать. Во-первых, мне просто нужно это обсудить:
Подозреваю, это произошло из-за того, что я не использовал SSH-ключ вместе со своим паролем.
99% уверен, что это не так. Почти каждый взлом веб-сервера, с которым я лично сталкивался и который устранял за 20+ лет опыта, был вызван недостатками на уровне приложений инетвсе, что связано с SSH или SFTP. Фактически, большинство веб-разработчиков/администраторов никогда не будут иметь дело с компрометацией уровня SSH/SFTP; недостатки в коде front-face являются основной точкой входа для многих вредоносных программ и необоснованных вторжений в общедоступные веб-системы.
А в вашем случае вы утверждаете следующее:
Это был Ubuntu 14, и у меня там было 6 Apache VirtualHosts. Все были живы.
Один из моих сайтов представлял собой установку 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уязвимость к «контузии».Этот сайт предоставляет хорошие инструменты для тестирования.чтобы узнать, уязвим ли ваш сервер для bashэксплойтов «shellshock». Честно говоря, это была одна из самых распространенных дыр безопасности, которую мне пришлось исправить с момента ее обнаружения. Так что есть большая вероятность, что это может быть слабым местом на сервере. Что касается того, как исправить 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, то все, что вам нужно сделать, это разобраться с конфигурационными вещами. Это мелочь по сравнению с очисткой кода с нуля.