Каковы явные признаки того, что сервер Linux был взломан? Существуют ли какие-либо инструменты, которые могут генерировать и отправлять отчеты по электронной почте на регулярной основе?
Если состояние неизвестно, то на самом деле нет пути. Вот почему так важно использовать надежные источники установки и настроить такие инструменты, как Tripwire, прежде чем подвергать его чему-либо еще, кроме себя.
Вы имеете в виду «треснувший». Хакинг - это то, как мы получили linux.
gbarry
Мой друг, сервер которого был размещен у нас, однажды попросил меня взглянуть на его сервер, так как с ним что-то странное. Как только я увидел бревна, я понял, что что-то случилось. Они пытались скрыть свои следы, и я думаю, что установили рут-кит, но немного запутались. Короче говоря, нам пришлось перестроить весь сервер с нуля. Это заняло всю ночь, а затем мы настроили некоторые инструменты аудита безопасности.
Мэтт
@Matt Mind говорит нам, какие инструменты? Все тот же сегодня?
Родриго
Ответы:
34
Храните где-нибудь нетронутую копию критических системных файлов (таких как ls, ps, netstat, md5sum) с md5sum из них и регулярно сравнивайте их с живыми версиями. Руткиты будут неизменно изменять эти файлы. Используйте эти копии, если вы подозреваете, что оригиналы были скомпрометированы.
aide или tripwire сообщат вам о любых файлах, которые были изменены - при условии, что их базы данных не были подделаны.
Сконфигурируйте системный журнал для отправки ваших файлов журналов на удаленный сервер журналов, где они не могут быть подделаны злоумышленником. Следите за этими удаленными лог-файлами на предмет подозрительной активности
регулярно читайте свои журналы - используйте logwatch или logcheck для синтеза критической информации.
Знай своих серверов . Знать, какие виды деятельности и журналы нормальные.
MD5 был сильно ослаблен, если не выброшен. Вы можете перейти к sha512.
Broam
12
Вы не
Я знаю, я знаю - но это параноидальная, грустная правда, правда;) Конечно, есть много намеков, но если бы система была нацелена конкретно - это было бы невозможно сказать. Приятно понимать, что ничто не может быть абсолютно безопасным. Но нам нужно работать для большей безопасности, поэтому вместо этого я укажу на все остальные ответы;)
Если ваша система была взломана, ни одному из ваших системных инструментов нельзя доверять, чтобы раскрыть правду.
Вы предполагаете, что у вашего злоумышленника есть некоторый навык, он хочет быть скрытным в любом случае, и не заинтересован просто в том, чтобы распространять спам и добавлять свой OC3 в ботнет. В наши дни вы обычно обнаруживаете, что с вашего сервера выходит огромное количество спама, обычно в перегруженной системе, чего не должно быть. В наши дни большинство "хакеров" мотивированы деньгами.
Эрни
2
В наши дни самые продвинутые инструменты атаки требуют нулевого навыка и легко доступны, а некоторые являются крайне скрытными по умолчанию и по замыслу. Ботнеты / зомби могут простаивать долгое время, прежде чем их можно использовать для нанесения вреда, но ошибки в инструментах атаки могут привести к нежелательным сбоям, странному поведению и т. Д.
Оскар Дювеборн
11
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, у вас должно быть некоторое руководство, чтобы начать копаться.
Это действительно полезно для моего домашнего сервера, где у меня нет времени, чтобы поддерживать систему как продуктивную рабочую систему. В любом случае, могу ли я использовать это в профессиональной среде и быть «относительным» уверенным в результатах? И чтобы ответ был 3 года: это все еще действительный метод для проверки на распространенную инфекцию в настоящее время в 2014 году?
хаб
7
Я подкреплю ответы, приведенные здесь, и добавлю один из моих.
find /etc /var -mtime -2
Это быстро подскажет, изменились ли какие-либо файлы вашего основного сервера за последние 2 дня.
SNORT® - это система с открытым исходным кодом для предотвращения и обнаружения вторжений, использующая язык на основе правил, который сочетает в себе преимущества методов проверки на основе сигнатур, протоколов и аномалий. На сегодняшний день Snort является самой распространенной технологией обнаружения и предотвращения вторжений, которая стала стандартом де-факто для отрасли.
Snort считывает сетевой трафик и может искать такие вещи, как «тестирование с помощью пера», когда кто-то просто выполняет полное сканирование метасплойтов на ваших серверах. Приятно знать такие вещи, на мой взгляд.
Используйте журналы ...
В зависимости от вашего использования вы можете настроить его так, чтобы вы знали, когда пользователь входит в систему или входит с нечетного IP-адреса, или всякий раз, когда root входит в систему, или когда кто-то пытается войти в систему. На самом деле у меня есть сервер, который посылает мне по электронной почте каждое сообщение журнала выше, чем Debug. Да, даже обратите внимание. Конечно, я отфильтровываю некоторые из них, но каждое утро, когда я получаю 10 писем о вещах, мне хочется исправить это, чтобы это перестало происходить.
Контролируйте свою конфигурацию - я фактически держу весь мой / etc в subversion, чтобы я мог отслеживать изменения.
Запустите сканирование. Такие инструменты, как Lynis и Rootkit Hunter, могут предупредить вас о возможных пробелах в ваших приложениях. Существуют программы, которые поддерживают хэш или дерево хешей всех ваших корзин и могут предупреждать вас об изменениях.
Контролируйте свой сервер - так же, как вы упомянули дисковое пространство - графики могут дать вам подсказку, если что-то необычное. Я использую кактусы , чтобы держать глаз на CPU, сетевого трафика, дискового пространства, температуры и т.д. Если что - то выглядит странно, это странно , и вы должны выяснить , почему это странно.
Проверьте свою историю bash, если она пуста, и вы ее не сбросили или не очистили, есть вероятность, что кто-то скомпрометировал ваш сервер.
Проверьте последний. Либо вы увидите неизвестные IP-адреса, либо он будет выглядеть очень пустым.
Затем, как указано в принятом ответе, системные файлы часто меняются, проверьте дату изменения. Однако они часто вмешиваются в измененную дату.
Они часто устанавливают другую версию ssh, работающую на случайном порту. Это часто скрывают в некоторых действительно странных местах. Обратите внимание, что обычно он будет переименован во что-то, кроме ssh. Поэтому проверьте netstat (может не сработать, так как его часто заменяют) и используйте iptables для блокировки любых неизвестных портов.
В любом случае, это ситуация, когда профилактика лучше лечения. Если вы были скомпрометированы, лучше всего отформатировать и начать заново. Почти невозможно подтвердить, что вы успешно убрали взлом.
Обратите внимание на следующее, чтобы ваш сервер не был взломан.
Там, где это возможно, внесите в черный список все ip и внесите в белый список требуемые ips.
Установите и настройте fail2ban
Используйте tripwire для обнаружения вторжений
Отслеживайте количество пользователей, вошедших в систему с помощью Nagios или zabbix. Даже если вы будете получать уведомления при каждом входе в систему, по крайней мере вы будете знать, когда кто-то еще играет.
Если возможно, держите ваш сервер на vpn и разрешайте ssh только через vpn ip. Защитите свой VPN.
Стоит отметить, что, попав на один сервер, они будут проверять историю вашего bash и искать с этого сервера другие серверы, к которым вы подключились через ssh. Затем они попытаются подключиться к этим серверам. Таким образом, если вы будете вынуждены перебором из-за плохого пароля, очень вероятно, что они смогут подключиться к другому серверу и тоже скомпрометировать их.
Это ужасный мир, повторяю, профилактика лучше лечения.
Вы должны проверить GuardRail. Он может сканировать ваш сервер ежедневно и сообщать вам, что изменилось приятным визуальным способом. Он не требует агента и может подключаться через SSH, поэтому вам не нужно складывать свою машину и ресурсы с агентом.
Это облачный сервис, который входит на ваш компьютер с правами root? Что произойдет, если сервис будет взломан?
хаб
Вам не нужно давать это корень. Вы также можете выбрать вместо этого использование агента, что означает, что ваша машина опрашивает вместо вызова SSH. Пароли для таких вещей, как DB, всегда хранятся на вашей машине, а не в облаке.
Ответы:
источник
Вы не
Я знаю, я знаю - но это параноидальная, грустная правда, правда;) Конечно, есть много намеков, но если бы система была нацелена конкретно - это было бы невозможно сказать. Приятно понимать, что ничто не может быть абсолютно безопасным. Но нам нужно работать для большей безопасности, поэтому вместо этого я укажу на все остальные ответы;)
Если ваша система была взломана, ни одному из ваших системных инструментов нельзя доверять, чтобы раскрыть правду.
источник
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, у вас должно быть некоторое руководство, чтобы начать копаться.
НТН.
источник
Я подкреплю ответы, приведенные здесь, и добавлю один из моих.
Это быстро подскажет, изменились ли какие-либо файлы вашего основного сервера за последние 2 дня.
Это из статьи об обнаружении взлома Как определить, был ли ваш сервер взломан.
источник
Из Как я могу обнаружить нежелательные вторжения на мои серверы?
Используйте IDS
Snort считывает сетевой трафик и может искать такие вещи, как «тестирование с помощью пера», когда кто-то просто выполняет полное сканирование метасплойтов на ваших серверах. Приятно знать такие вещи, на мой взгляд.
Используйте журналы ...
В зависимости от вашего использования вы можете настроить его так, чтобы вы знали, когда пользователь входит в систему или входит с нечетного IP-адреса, или всякий раз, когда root входит в систему, или когда кто-то пытается войти в систему. На самом деле у меня есть сервер, который посылает мне по электронной почте каждое сообщение журнала выше, чем Debug. Да, даже обратите внимание. Конечно, я отфильтровываю некоторые из них, но каждое утро, когда я получаю 10 писем о вещах, мне хочется исправить это, чтобы это перестало происходить.
Контролируйте свою конфигурацию - я фактически держу весь мой / etc в subversion, чтобы я мог отслеживать изменения.
Запустите сканирование. Такие инструменты, как Lynis и Rootkit Hunter, могут предупредить вас о возможных пробелах в ваших приложениях. Существуют программы, которые поддерживают хэш или дерево хешей всех ваших корзин и могут предупреждать вас об изменениях.
Контролируйте свой сервер - так же, как вы упомянули дисковое пространство - графики могут дать вам подсказку, если что-то необычное. Я использую кактусы , чтобы держать глаз на CPU, сетевого трафика, дискового пространства, температуры и т.д. Если что - то выглядит странно, это странно , и вы должны выяснить , почему это странно.
источник
Я просто хотел бы добавить к этому:
Проверьте свою историю bash, если она пуста, и вы ее не сбросили или не очистили, есть вероятность, что кто-то скомпрометировал ваш сервер.
Проверьте последний. Либо вы увидите неизвестные IP-адреса, либо он будет выглядеть очень пустым.
Затем, как указано в принятом ответе, системные файлы часто меняются, проверьте дату изменения. Однако они часто вмешиваются в измененную дату.
Они часто устанавливают другую версию ssh, работающую на случайном порту. Это часто скрывают в некоторых действительно странных местах. Обратите внимание, что обычно он будет переименован во что-то, кроме ssh. Поэтому проверьте netstat (может не сработать, так как его часто заменяют) и используйте iptables для блокировки любых неизвестных портов.
В любом случае, это ситуация, когда профилактика лучше лечения. Если вы были скомпрометированы, лучше всего отформатировать и начать заново. Почти невозможно подтвердить, что вы успешно убрали взлом.
Обратите внимание на следующее, чтобы ваш сервер не был взломан.
Стоит отметить, что, попав на один сервер, они будут проверять историю вашего bash и искать с этого сервера другие серверы, к которым вы подключились через ssh. Затем они попытаются подключиться к этим серверам. Таким образом, если вы будете вынуждены перебором из-за плохого пароля, очень вероятно, что они смогут подключиться к другому серверу и тоже скомпрометировать их.
Это ужасный мир, повторяю, профилактика лучше лечения.
источник
Немного покопавшись, есть еще и то, что я перечислил выше, среди прочего: http://www.chkrootkit.org/ и http://www.rootkit.nl/projects/rootkit_hunter.html.
источник
Вы должны проверить GuardRail. Он может сканировать ваш сервер ежедневно и сообщать вам, что изменилось приятным визуальным способом. Он не требует агента и может подключаться через SSH, поэтому вам не нужно складывать свою машину и ресурсы с агентом.
Лучше всего, это бесплатно до 5 серверов.
Проверьте это здесь:
https://www.scriptrock.com/
источник