Як дізнатись, чи мій сервер Linux був зламаний?

Які ознаки того, що зламався сервер Linux? Чи є інструменти, які можуть генерувати та надсилати електронний звіт про аудит за розкладом?

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

Ви цього не робите.

Я знаю, я знаю - але це справді параноїдальна, сумна правда;) Звичайно, є багато підказок, але якби система була орієнтована конкретно - це неможливо сказати. Добре розуміти, що ніколи ніколи не є повністю безпечним. Але нам потрібно працювати над більш безпечним, тому я накажу на всі інші відповіді замість цього;)

Якщо ваша система була порушена, жодному із ваших системних інструментів не можна довіряти, щоб розкрити правду.

Tripwire - це поширений інструмент - він повідомляє вас про зміну системних файлів, хоча, очевидно, потрібно встановити його заздалегідь. Інакше такі елементи, як нові облікові записи користувачів, про які ви не знаєте, дивні процеси та файли, які ви не розпізнаєте, або збільшення використання пропускної здатності без видимих ​​причин - це звичайні ознаки.

Інші системи моніторингу, такі як Zabbix, можуть бути налаштовані так, щоб повідомляти вас про зміну файлів, таких як / etc / passwd.

Деякі речі, які мене підкреслили в минулому:

• Високе навантаження на систему, яка повинна працювати в режимі очікування
• Дивні segfault, наприклад. від стандартних утиліт на зразок ls(це може статися зі зламаними наборами кореня)
• Приховані каталоги в /або /var/(більшість дітей із сценарію занадто дурні або ледачі, щоб покрити свої доріжки)
• netstat показує відкриті порти, яких там не повинно бути
• Демони в списку процесів, для яких ви зазвичай використовуєте різні аромати (наприклад bind, але ви завжди використовуєте djbdns)

Крім того, я виявив, що є одна достовірна ознака того, що поле порушено: якщо у вас погані почуття старанності (з оновленнями тощо) адміністратора, від якого ви успадкували систему, пильно стежте за цим!

Існує метод перевірки зламаних серверів через kill-

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

Коли ваш сервер зламано / встановлено руткіт, одне з перших речей - це сказати ядру приховати порушені процеси з таблиць процесів і т. Д. Однак він може робити всілякі круті речі в просторі ядра, щоб вилазити з процесів. І це означає, що це

a) Ця перевірка не є обширною перевіркою, оскільки добре кодовані / інтелектуальні руткіти забезпечать, що ядро ​​відповість "процесом не існує", що робить цю перевірку зайвою. b) У будь-якому випадку, коли на зламаному сервері запущений "поганий" процес, PID зазвичай не відображатиметься під / proc.

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

Якщо деякі процеси виявляються запущеними, але вони не повідомляються в / proc, у вас, ймовірно, є проблеми в будь-якому випадку.

Ось баш сценарій, який реалізує все це - https://gist.github.com/1032229 . Збережіть це в якомусь файлі та виконайте його, якщо ви знайдете процес, який не відображається у програмі proc, у вас має бути деякий привід, щоб почати копати.

HTH.

Я другий відповіді, наведені тут, і додам один із своїх.

find /etc /var -mtime -2

Це дасть вам швидку інформацію про те, чи змінився будь-який з основних файлів сервера за останні 2 дні.

Це зі статті про виявлення зламу. Як виявити, чи зламався ваш сервер.

Звідки я можу виявити небажані вторгнення на своїх серверах?

• Використовуйте IDS

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

  Snort читає мережевий трафік і може шукати такі речі, як "диск за допомогою тестування пера", де хтось просто запускає ціле сканування метасплайта на ваші сервери. На мій погляд, добре знати такі речі.

• Використовуйте журнали ...

  Залежно від вашого використання ви можете налаштувати його, щоб ви знали, коли користувач увійде в систему, або ввійде через непарний IP, або кожен раз, коли користувач увійде в систему, або коли хтось спробує увійти. У мене насправді сервер надсилає по електронній пошті мені кожне повідомлення журналу вище, ніж налагодження. Так, навіть зауважте. Я, звичайно, фільтрую деякі з них, але щоранку, коли отримую 10 електронних листів про речі, це змушує мене виправити це, щоб це перестало відбуватися.

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

• Виконати сканування. Такі інструменти, як Lynis та Rootkit Hunter, можуть повідомляти про можливі отвори у ваших програмах. Є програми, які підтримують хеш-хеш-дерево всіх ваших бункерів і можуть попередити вас про зміни.

• Стежте за своїм сервером - так само, як ви згадали на диску, графіки можуть дати вам підказку, якщо щось незвичне. Я використовую Кактуси, щоб слідкувати за процесором, мережевим трафіком, дисковим простором, температурою тощо. Якщо щось виглядає дивно, це не дивно, і ви повинні дізнатися, чому це незвично.

Я просто хотів би додати до цього:

Перевірте свою історію баш-програм, якщо вона порожня, і ви її не зняли чи випорожнили, є хороша можливість, що хтось порушив ваш сервер.

Перевірте останню. Або ви побачите невідомі IP-адреси, або вони будуть виглядати дуже порожніми.

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

Вони часто встановлюють іншу версію ssh, що працює на випадковому порту. Це часто приховується в деяких дійсно дивних місцях. Зауважте, що зазвичай він буде перейменований на щось інше, ніж на ssh. Тому перевірте netstat (може не працювати, оскільки вони часто його замінюють) і використовуйте iptables для блокування будь-яких невідомих портів.

У будь-якому випадку, це ситуація, коли профілактика краще, ніж лікування. Якщо у вас виникли компрометації, краще просто відформатувати та почати заново. Підтвердити, що ви успішно очистили злом, майже неможливо.

Зверніть увагу на наступне, щоб запобігти злому вашого сервера.

1. Змінити ssh-порт
2. Забороніть корінь від можливості входу в систему
3. дозволяти лише певним користувачам
4. Запобігання входу пароля
5. Використовуйте ключі ssh, бажані ключі, захищені паролем
6. Де можливо, чорний список усіх ip та білого списку потрібних ips.
7. Встановлення та налаштування fail2ban
8. Використовуйте трикутний провід для виявлення вторгнень
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/