Как найти утечку в системе безопасности после вторжения в скайнет?
Несколько дней назад на сервере друга произошло вторжение. При атаке был установлен новый демон SSH, который пропускал любую действительную учетную запись без предоставления действительного пароля. После входа в систему каждая учетная запись автоматически получала root-права, а сервер приветствовал следующее:
Атака также удалила записи системного журнала, которые показывали вторжение (мы выяснили это с помощью журнала системного журнала) и изменила путь к местоположению пакета Debian в /etc/apt/sources.list,
Сервер работает под управлением Debian Etch и не обновлялся во время атаки: на Apache/PHP не были установлены все обновления безопасности. Мы думаем, что вторжение могло произойти из-за этих отсутствующих обновлений, но мы на самом деле не уверены. За день до атаки мы установили Wordpress 3.0.1; но мы не знаем, была ли установка Wordpress открытием двери.
Есть ли способ узнать, какая утечка безопасности на сервере допустила вторжение?
2 ответа
После того, как злоумышленник получил 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 или более часов, особенно если вы делаете это впервые.
Вам, вероятно, не повезло, если у вас нет какой-то удаленной регистрации.
Я думаю, что лучше записать это на "усвоенный урок", переустановить систему с нуля (серьезно, не пропустите этот шаг!), А затем сохранить новую систему исправленной.
По моему опыту, гораздо лучше иметь автоматические обновления и рисковать очисткой после плохого автоматического патча, чем делать обновления вручную и рисковать отстать, и это может произойти. В первом случае, в очень редком случае плохого патча для вендора / дистрибутива, вы можете исправить ситуацию, потратив на это несколько минут. При компрометации системы это целое восстановление и потеря большого количества времени.