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

Мой Linux-сервер был взломан. Как мне узнать, как и когда это было сделано?

У меня есть домашний сервер с настольным дистрибутивом Ubuntu. Я нашел это в своем crontab

* * * * * /home/username/ /.access.log/y2kupdate >/dev/null 2>&1

и, глядя в этот каталог (пробел после имени пользователя / - это имя каталога), я обнаружил множество скриптов, которые явно делают то, чего не должны.

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

Какие файлы журналов мне следует искать? Единственные известные мне серверы, работающие на компьютере, - это sshd и lighttpd.

Что мне делать, чтобы определить, повторится ли подобное снова?

Это своего рода тема сама по себе; вы можете использовать Google для криминалистики Linux для получения дополнительной информации. По сути, вам нужно сначала создать образ ваших дисков для автономного анализа, затем стереть компьютер и установить с чистого листа.

И запомните все мелочи. Любой человек, использующий компьютер, мог получить доступ к своим паролям. Измените пароли, оставьте его в автономном режиме и т. Д., Пока не получите его в «чистой комнате» (изолированной виртуальной машине).

В противном случае придется много проверять журналы (которые можно подделать) и проверять свои приложения (php-скрипты? Базы данных? Обновлены последние исправления? Другие пользователи выдают пароли?)

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

Что касается будущих атак, то в зависимости от того, насколько безопасным вы хотите его сделать, вы можете начать с перенаправления журналов в систему, которая используется только для сохранения системных журналов. Нет другого доступа, чтобы уменьшить след атаки.

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

И, конечно же, будьте в курсе обновлений и запускайте программное обеспечение для сканирования, которое проверяет наличие руткитов.

Опять же, безопасность - это не простая вещь. Это тоже может быть специальностью. Многоуровневая безопасность может быть такой же строгой, как проверка хостов / IP-адресов, которые не принадлежат вашей сети, шифрование всего доступа к системе, отправка вам ежедневных журналов изменений, обнаруженных в вашей системе, и настройка приманки в вашей сети для ищите странную активность (почему мой сервер пытается подключиться к порту 25 на компьютере-приманке?)

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

РЕДАКТИРОВАТЬ - некоторые другие вещи, которые приходят мне в голову, поскольку вы используете SSH - установите denyhosts. Его можно настроить так, чтобы автоматические атаки на вашу систему на SSHD блокировались после X попыток. Его также можно настроить для обновления с других серверов denyhost в «облаке» для совместного использования заблокированных IP-адресов, чтобы минимизировать автоматические атаки. Вы также можете переместить порт, который он слушает; многие люди отмечают, что это просто безопасность через неясность, но, учитывая количество сканированных ботов, это значительно сокращает случайные попытки взлома.

Сначала убедитесь, что компьютер отключен от любых сетей.
Во-вторых, убедитесь, что вы удалили с дисков все важные данные, прежде чем снова загружать взломанную ОС.

Начните с проверки отметок времени в файлах, о которых идет речь. Часто они точны.
Перекрестные ссылки на те, у которых есть журнал httpd и журнал аутентификации, если они не были удалены. Если один другой был уничтожен, вы можете поспорить, что это было средством входа. Если они все еще в порядке, вы можете почерпнуть дополнительную информацию о том, как они попали в журнал.

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

Вы упомянули, что эти две службы работают, был ли установлен хороший брандмауэр, предотвращающий доступ ко всему остальному? Вы разрешили SSH на 22-м порту; легко ли угадать ваш логин; вы разрешили вход по паролю; было ли у вас какое-либо ограничение реальной скорости для входа в систему по паролю? Было ли у вас установлено какое-либо дополнительное программное обеспечение с lighttpd; perl; php; cgi; CMS или подобное? Была ли у вас установлена ​​обновленная версия всего программного обеспечения; Вы подписываетесь на уведомления безопасности для всего программного обеспечения, которое вы запускаете, и внимательно оцениваете все уведомления, чтобы увидеть, применимы ли они к программному обеспечению, которое вы запускаете / публикуете?