Назад | Перейти на главную страницу

Как найти утечку безопасности после вторжения в Скайнет?

Несколько дней назад на сервер друга произошло вторжение. В ходе атаки был установлен новый демон SSH, который пропускал любую действительную учетную запись без предоставления действительного пароля. После входа в систему каждая учетная запись автоматически получила права root, и сервер приветствовал следующее:

Атака также удалила записи системного журнала, которые указывали на вторжение (мы выяснили это с помощью журнала системного журнала), и изменила путь к расположению пакета Debian в /etc/apt/sources.list.

Сервер работает под управлением Debian Etch и не обновлялся во время атаки: на Apache / PHP не были установлены все обновления безопасности. Мы думаем, что вторжение могло произойти из-за этих отсутствующих обновлений, но на самом деле мы не уверены. За день до атаки мы установили Wordpress 3.0.1; но мы не знаем, открыла ли вам двери установка Wordpress.

Есть ли способ узнать, какая утечка безопасности на сервере позволила вторжение?

Вам, вероятно, не повезло, если у вас нет какой-либо удаленной регистрации.

Я думаю, что лучше всего списать это на «усвоенный урок», переустановить систему с нуля (серьезно, не пропускайте этот шаг!), А затем оставить исправления для новой системы.

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

После того, как злоумышленник получил root-права, часто трудно сказать, как он попал, потому что он может изменить систему, включая журналы. Если у вас нет журналов, отправляемых в другую систему по сети, вам может не повезти, особенно если вы упомянули изменяемые журналы.

Очевидно, что усвоенный урок заключается в том, что вам нужно быть в курсе обновлений. Обычно мы применяем исправления в течение дня после их выпуска через yum / apt-get.

Обратите внимание, что атака на PHP, Apache или Wordpress, вероятно, дала бы злоумышленнику только привилегии веб-сервера. Но из вашего описания кажется, что они точно получили root. Так что, если они действительно вошли через веб-приложение, существовал еще один компромисс, позволяющий им перейти от Apache к root. Но мне также интересно, проникли ли они через слабый пароль root на SSH и т. Д.

Однако знание метода атаки, вероятно, не позволит вам избавиться от него. На данный момент машина очень серьезно взломана, судя по вашему описанию, и лучше всего установить новую ОС с нуля и настроить резервную копию системы. Проверяйте все данные и программное обеспечение, которые вы переносите из старого ящика. Починить скомпрометированный ящик ОЧЕНЬ сложно.

В любом случае, чтобы ответить на ваш вопрос о том, есть ли способ узнать, вот несколько общих мест, где можно найти, что произошло:

  • / var / log / syslog или / var / log / messages - ищите, когда могла произойти атака, возможно, по пробелам в журнале или действиям, которые вы не можете объяснить.
  • Другие журналы, возможно, они не стерлись, например / var / log / security
  • .bash_history различных учетных записей, включая root и веб-сервер. Это может предоставить команды, которые они выполняли, или информацию о том, что было сделано.
  • Ищите запущенные процессы, которые вы не узнаете, или процессы, которые вы знаете, которые могут запускаться из необычных каталогов или имен. Посмотрите на / proc / $ PID и / proc / $ PID / fd различных идентификаторов ($ PID) процессов, которые вы видите запущенными.
  • Возможно, «последний» что-то вам скажет, но, вероятно, они это стерли.
  • rkhunter может помочь вам сказать, что взломано в системе, и поможет найти, где вы можете найти дополнительную информацию.
  • Журналы Apache могут показывать некоторые признаки необычной активности, но часто бывает сложно отфильтровать атаки, которые вы получаете все время, от атаки, которая фактически взломала систему.

Большая часть этой работы - это серьезная взаимная корреляция между различными файлами журналов, чтобы выяснить, что интересно, а что просто шум.

Проведение такого рода расследования - непростая задача. Вероятно, это займет 4 или более часов, особенно если вы делаете это впервые.