Как я узнаю, что мой Linux-сервер был взломан?

Каковы явные признаки того, что сервер Linux был взломан? Существуют ли какие-либо инструменты, которые могут генерировать и отправлять отчеты по электронной почте на регулярной основе?

1. Храните где-нибудь нетронутую копию критических системных файлов (таких как ls, ps, netstat, md5sum) с md5sum из них и регулярно сравнивайте их с живыми версиями. Руткиты будут неизменно изменять эти файлы. Используйте эти копии, если вы подозреваете, что оригиналы были скомпрометированы.
2. aide или tripwire сообщат вам о любых файлах, которые были изменены - при условии, что их базы данных не были подделаны.
3. Сконфигурируйте системный журнал для отправки ваших файлов журналов на удаленный сервер журналов, где они не могут быть подделаны злоумышленником. Следите за этими удаленными лог-файлами на предмет подозрительной активности
4. регулярно читайте свои журналы - используйте logwatch или logcheck для синтеза критической информации.
5. Знай своих серверов . Знать, какие виды деятельности и журналы нормальные.

Вы не

Я знаю, я знаю - но это параноидальная, грустная правда, правда;) Конечно, есть много намеков, но если бы система была нацелена конкретно - это было бы невозможно сказать. Приятно понимать, что ничто не может быть абсолютно безопасным. Но нам нужно работать для большей безопасности, поэтому вместо этого я укажу на все остальные ответы;)

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

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

Другие системы мониторинга, такие как Zabbix, могут быть настроены на оповещение об изменении файлов, таких как / etc / passwd.

Некоторые вещи, которые предупредили меня в прошлом:

• Высокая нагрузка на систему, которая должна простаивать
• Странные сегфолты, например. из стандартных утилит, как ls(это может случиться с сломанными рутами)
• Скрытые каталоги в /или /var/(большинство сценаристов слишком глупы или ленивы, чтобы скрыть свои следы)
• netstat показывает открытые порты, которых там быть не должно
• Демоны в списке процессов, которые вы обычно используете в разных вариантах (например bind, но вы всегда используете djbdns)

Кроме того, я обнаружил один надежный признак того, что ящик скомпрометирован: если у вас плохое предчувствие усердия (с обновлениями и т. Д.) Администратора, от которого вы унаследовали систему, следите за ней!

Есть метод проверки взломанных серверов через kill-

По сути, когда вы запускаете «kill -0 $ PID», вы посылаете сигнал nop для обработки идентификатора $ PID. Если процесс запущен, команда kill завершится нормально. (FWIW, так как вы передаете сигнал nop kill, с процессом ничего не произойдет). Если процесс не запущен, команда kill не будет выполнена (состояние выхода меньше нуля).

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

a) Эта проверка не является обширной проверкой, поскольку хорошо закодированные / интеллектуальные руткиты гарантируют, что ядро ​​ответит ответом "процесс не существует", что сделает эту проверку избыточной. б) В любом случае, когда на взломанном сервере запущен «плохой» процесс, его PID обычно не отображается в / proc.

Таким образом , если вы здесь до сих пор, метод состоит в том, чтобы убить -0 каждого доступного процесса в системе (что-нибудь из 1 -> / proc / sys / kernel / pid_max) и посмотреть, есть ли процессы, которые выполняются, но не сообщаются в / proc.

Если некоторые процессы запускаются, но не регистрируются в / proc, у вас, вероятно, возникнут проблемы, если вы посмотрите на них.

Вот скрипт bash, который реализует все это - https://gist.github.com/1032229 . Сохраните это в каком-то файле и выполните его, если вы обнаружите, что процесс не сообщается в proc, у вас должно быть некоторое руководство, чтобы начать копаться.

НТН.

Я подкреплю ответы, приведенные здесь, и добавлю один из моих.

find /etc /var -mtime -2

Это быстро подскажет, изменились ли какие-либо файлы вашего основного сервера за последние 2 дня.

Это из статьи об обнаружении взлома Как определить, был ли ваш сервер взломан.

Из Как я могу обнаружить нежелательные вторжения на мои серверы?

• Используйте IDS

  SNORT® - это система с открытым исходным кодом для предотвращения и обнаружения вторжений, использующая язык на основе правил, который сочетает в себе преимущества методов проверки на основе сигнатур, протоколов и аномалий. На сегодняшний день Snort является самой распространенной технологией обнаружения и предотвращения вторжений, которая стала стандартом де-факто для отрасли.

  Snort считывает сетевой трафик и может искать такие вещи, как «тестирование с помощью пера», когда кто-то просто выполняет полное сканирование метасплойтов на ваших серверах. Приятно знать такие вещи, на мой взгляд.

• Используйте журналы ...

  В зависимости от вашего использования вы можете настроить его так, чтобы вы знали, когда пользователь входит в систему или входит с нечетного IP-адреса, или всякий раз, когда root входит в систему, или когда кто-то пытается войти в систему. На самом деле у меня есть сервер, который посылает мне по электронной почте каждое сообщение журнала выше, чем Debug. Да, даже обратите внимание. Конечно, я отфильтровываю некоторые из них, но каждое утро, когда я получаю 10 писем о вещах, мне хочется исправить это, чтобы это перестало происходить.

• Контролируйте свою конфигурацию - я фактически держу весь мой / etc в subversion, чтобы я мог отслеживать изменения.

• Запустите сканирование. Такие инструменты, как Lynis и Rootkit Hunter, могут предупредить вас о возможных пробелах в ваших приложениях. Существуют программы, которые поддерживают хэш или дерево хешей всех ваших корзин и могут предупреждать вас об изменениях.

• Контролируйте свой сервер - так же, как вы упомянули дисковое пространство - графики могут дать вам подсказку, если что-то необычное. Я использую кактусы , чтобы держать глаз на CPU, сетевого трафика, дискового пространства, температуры и т.д. Если что - то выглядит странно, это странно , и вы должны выяснить , почему это странно.

Я просто хотел бы добавить к этому:

Проверьте свою историю bash, если она пуста, и вы ее не сбросили или не очистили, есть вероятность, что кто-то скомпрометировал ваш сервер.

Проверьте последний. Либо вы увидите неизвестные IP-адреса, либо он будет выглядеть очень пустым.

Затем, как указано в принятом ответе, системные файлы часто меняются, проверьте дату изменения. Однако они часто вмешиваются в измененную дату.

Они часто устанавливают другую версию ssh, работающую на случайном порту. Это часто скрывают в некоторых действительно странных местах. Обратите внимание, что обычно он будет переименован во что-то, кроме ssh. Поэтому проверьте netstat (может не сработать, так как его часто заменяют) и используйте iptables для блокировки любых неизвестных портов.

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

Обратите внимание на следующее, чтобы ваш сервер не был взломан.

1. Изменить порт SSH
2. Запретить root доступ для входа в систему
3. разрешить только определенным пользователям
4. Запретить пароль для входа
5. Используйте ключи SSH, предпочтительные ключи, защищенные паролем
6. Там, где это возможно, внесите в черный список все ip и внесите в белый список требуемые ips.
7. Установите и настройте fail2ban
8. Используйте tripwire для обнаружения вторжений
9. Отслеживайте количество пользователей, вошедших в систему с помощью Nagios или zabbix. Даже если вы будете получать уведомления при каждом входе в систему, по крайней мере вы будете знать, когда кто-то еще играет.
10. Если возможно, держите ваш сервер на vpn и разрешайте ssh только через vpn ip. Защитите свой VPN.

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

Это ужасный мир, повторяю, профилактика лучше лечения.

Немного покопавшись, есть еще и то, что я перечислил выше, среди прочего: http://www.chkrootkit.org/ и http://www.rootkit.nl/projects/rootkit_hunter.html.

Вы должны проверить GuardRail. Он может сканировать ваш сервер ежедневно и сообщать вам, что изменилось приятным визуальным способом. Он не требует агента и может подключаться через SSH, поэтому вам не нужно складывать свою машину и ресурсы с агентом.

Лучше всего, это бесплатно до 5 серверов.

Проверьте это здесь:

https://www.scriptrock.com/