Возможный дубликат:
Мой сервер был взломан в АВАРИИ
Я получил 32-битный Debian VPS от http://linode.com и я действительно не делал никаких дополнительных настроек для его защиты (порт 22; пароль включен).
Похоже, что с моего IP-адреса происходит ssh-сканирование, меня помечают, поскольку это противоречит TOS. Я пользуюсь SSH только у своего домашнего интернет-провайдера Comcast, на котором я запускаю Linux.
Это обычное дело при получении новых vps? Есть ли какие-нибудь стандартные советы по настройке безопасности? Я совершенно не понимаю, как мою машину обвинили в этом сканировании ssh.
Лично мне кажется, что вас скомпрометировали. Я бы переустановил ОС, а затем перенастроил SSH с помощью:
Многие компрометации системы являются результатом сканирования и перебора слабого пароля. К сожалению, это стало частью повседневной жизни в Интернете, и вам необходимо защитить свой сервер от таких атак. Вот хорошее руководство для начала:
Это выглядело как комментарий к ответу freedom_is_chaos, но стало слишком большим ...
@Meder: другие службы, такие как сам SSHd, ведут журналы, а не только Apache. Хотя любой хорошо закодированный эксплойт (или эксплойт, созданный с помощью готового генератора эксплойтов хорошего качества), вероятно, найдет свои следы, как только попадет внутрь.
Неудачно выбранный пароль для root или учетная запись с достаточными привилегиями через sudo является наиболее вероятным вектором атаки, учитывая, что эксплойт устанавливает много SSH-соединений (чтобы попытаться распространиться на другие серверы так же, как он заразил ваш). Вам нужно остановить ВМ немедленно. Чем дольше он работает, тем дольше возникает проблема, потенциально вызывающая новые инфекции.
Если у вас есть какие-либо данные на виртуальной машине, которые вы хотите сохранить, немедленно выключите ее - не возитесь с созданием резервных копий в первую очередь, потому что, если что-то не изменилось с тех пор, как я в последний раз использовал службы Linode, вы можете создать новую, неиспользуемую виртуальную машину и прикрепить старый диск к нему снимать данные. Однако будьте осторожны, чтобы не доверять этим данным, особенно исполняемым двоичным файлам и скриптам - дважды проверьте все, что вы используете, на случай, если они были изменены, чтобы упростить будущие эксплойты (вы не хотите случайно скопировать в новую виртуальную машину черный ход, который был установлен в старую).
Также прочтите страницу, на которую ссылается Тасаро. Это похоже на хорошее резюме того, как попытаться защитить простую виртуальную машину. Если вы не будете (по какой-то причине) использовать аутентификацию на основе ключей, по крайней мере, используйте надежные пароли - не беспокойтесь о том, что они запоминаются, так как вы можете хранить их в чем-то вроде держать вместо того, чтобы запоминать их (просто убедитесь, что вы храните данные для хранения в сейфе). В то время как удаленный эксплойт может легко добраться до чего-то вроде "elephant4" с помощью перебора на основе словаря, вряд ли он найдет что-то вроде "eGz3nk7aVdN7OIChoPy7". Также убедитесь, что вы используете разные пароли для разных служб - таким образом, если одному удастся каким-то образом ускользнуть, вы поставите под угрозу только один сервис, а не многие другие.
Наиболее вероятное объяснение заключается в том, что ваш сервер был взломан.
Что дальше?
Получив новый образ, не забудьте отключить вход в систему root через SSH. Таким образом, вы вынуждены сначала войти в систему через учетную запись пользователя, а затем подняться до root, используя su. Не давайте обычным учетным записям пользователей привилегий sudo, которые в этом не нуждаются.
Также неплохо использовать AllowUsers в вашей конфигурации SSH, чтобы ограничить доступ SSH для тех, кто в нем нуждается. Если возможно, убедитесь, что у этих пользователей есть надежные пароли.
Зачем переустанавливать с нуля?
Если вы продолжите использовать ту же систему, вы никогда не сможете быть уверены, что удалили все лазейки, установленные злоумышленником. Если злоумышленник использовал ошибку повышения привилегий, чтобы получить корень, то он / она даже смог бы заменить системные и / или загрузочные двоичные файлы.