Що таке rootkits, і як з ними боротися

Що таке rootkits, і як з ними боротися

На новий сервер встановлений Linux останнього випуску, прибрані всі зайві сервіси, firewall налаштований так, що заздрять друзі. Тепер можна сидіти почитувати художню літературу і попивати каву. А ось і ні. Так може думати адмін, який жодного разу не пробував свої сили у зломі своїх систем.

На жаль, перебуваючи на курсах, помітив дивну закономірність. Деякі з присутніх наосліп довіряли firewall, грунтуючись, як правило, на дуже простому припущенні, що якщо він відсіває непотрібну частину трафіку, то зломщикові просто немає шляхів для проникнення на комп'ютер. Так, дійсно, firewall, діючи за класичною схемою «свій-чужий», відсікає неугодні адміністратору пакети. Але якщо, наприклад, відкритий 80 порт для доступу до веб-сервера, то і пакети, спрямовані на такий порт, безперешкодно пройдуть через нього і, природно, дотримуючись законів Мерфі, обов'язково знайдеться вразливість в такому «легальному» сервісі, не кажучи вже, що сам firewall може стати об'єктом атаки. Далі, як то кажуть, все це вже справа часу.

Щоб мати можливість і далі повертатися в взломаную систему, при цьому, щоб системний адміністратор не міг їх побачити, а система їх дії не реєструвала, нападник встановлює сучасний варіант троянського коня, набір утиліт - rootkits. Зазвичай в цей набір входить sniffer, за допомогою якого прослуховується мережу для можливого перехоплення цінної інформації (пароля, наприклад), модифікований набір основних системних програм (ps, ls, who, find, netstat, ifconfig.), Скрипти для чищення логів. Для дистанційного керування запускається нелегальний демон віддаленого доступу, що відкриває мережевий порт, який «не помічають» модифіковані утиліти. При цьому, щоб зберегти максимальне наближення до оригінального файлу, трояненние утиліти імітують ту ж дату створення файлу і розмір.

Невелика історія розвитку rootkits

silvio. там до недавнього часу лежав файл runtime-kernel-kmem-patching.txt, але зараз чомусь пропав або, наприклад, цілих три статті в номері 58 (файли р58-0х06, р58-0х07, р58-0х08) журналу Phrack «Sub proc_root Quando Sumus (Advances in Kernel Hacking) »,« Linux on-the-fly kernel patching without LKM »і« IA32 ADVANCED FUNCTION HOOKING », і є інформація в наступних номерах журналу.

Як захиститися від rootkits?

# Nmap -v -P0 -sU -sT -p 1-65535 IP_ADDRESS

Таким чином, перевіримо все TCP- і UDP-порти, хоча це і займе деякий час.

можна отримати уявлення про змінені файлах. Якщо файл виявиться порожньою, то змін немає, але, правда, це ще не підтверджує, що система чиста. Але от якщо з'являться подібні рядки:

S.5. T c /etc/hotplug/usb.usermap
S.5. T c / etc / sysconfig / pcmcia

то змінені файли необхідно перевірити:

  • M - відрізняється стан (включаючи дозволи і тип файлу).
  • S - відрізняється розмір файлу.
  • 5 - відрізняється сума MD5.
  • D - не відповідає число основних / другорядних пристроїв.
  • L - не відповідає шлях readLink (2).
  • U - відрізняється користувач-власник.
  • G - відрізняється група-власник.
  • T - відрізняється mTime.

Щоб не возитися з усією системою і трохи спростити завдання, в першу чергу необхідно перевіряти пакети net-tools, fileutils, util-linux, procps, psmisc, і findutils (командою rpm -V Имя_Пакета). Правда, в наведеному прикладі це все конфігураційні файли, в яких, природно, з'явилися зміни в порівнянні з оригіналом, а ось якщо будуть потрапляти файли з каталогів, що містять виконувані файли, то необхідно насторожитися. За допомогою команди rpm -qf / path / to / file можна перевірити, чи є даний файл частиною пакета. Виявлене розбіжність можна, природно, попередньо зберігши змінені файли для подальшого вивчення, тут же відновити.

# Rpm -Uvh -force <имя_файла.rpm>

rammer / aide.html) дозволяють автоматизувати процес підрахунку контрольних сум і видачі результату порівняння. Але при їх використанні бажано базу тримати на окремому носії, тим самим також захищаючи її від модифікації. Також можливе зараження може підказати незвичне поведінку улюбленої утиліти, тому що її протрояненний варіант може мати трохи відрізняються опції запуску.

ROOTDIR is `/"
Checking `amd". Not found
Checking `basename". Not infected
Checking `biff". Not found
Checking `chfn". Not infected

Утиліта має три, на мій погляд, заслуговують ключа роботи. Якщо хочете перевірити систему, завантажившись з іншого комп'ютера або за допомогою LiveCD, то за допомогою ключа -r можна вказати каталог, який буде використаний як кореневої при пошуку.

# ./chkrootkit -r / mnt / test

Так як chkrootkit використовує для своєї роботи деякі типові UNIX-утиліти (awk, cut, egrep, find, head, id, ls, netstat, ps, strings, sed, uname), які можуть бути компрометувати, то щоб уникнути помилки при пошуку необхідно використовувати статично скомпільовані версії цих утиліт (знову ж зберігши їх де-небудь подалі), а каталог, де вони знаходяться, вказати за допомогою ключа -p:

# ./chkrootkit -p / mnt / safebin

Для дослідження підозрілих рядків в бінарних файлах можна її запустити в дослідному режимі, використавши ключ -х:

# ./chkrootkit -x | more

Утиліта ifpromisc дозволяє визначити, чи знаходиться мережевий інтерфейс в PROMISCIOUS-режимі.

eth0 is not promisc

За виявлення троянів в модулях ядра відповідають утиліти chkproc і chkdirs. Утиліти chklastlog, chkwtmp і check_wtmpx перевіряють видалення даних в лог-файлах, strings забезпечує роботу з рядками. І ще на сайті утиліти є велика кількість посилань на матеріали по темі статті.

Команда find (якщо їй можна довіряти) може виявити файли і каталоги, чиї імена починаються з точки (або з пробілу з точкою), які зазвичай використовують зломщики для зберігання своїх даних.

SysCall Address
sys_exit 0xc0117ce4
sys_fork 0xc0108ebc
sys_read 0xc012604c

І тепер, періодично порівнюючи отримані значення, можна перевіряти наявність даного виду rootkit в системі. І якщо на виході отримаємо щось схоже на:

sys_kill 0xc28465d4 WARNING! Should be at 0xc01106b4

то варто трохи задуматися над тим, що діється в системі.

# Gcc -o rkscan rkscan1.0.c

І запускаємо під звичайним користувачем, тому що під root програма лається і працювати не хоче.

*** Don "t run this scanner as root. ***

-= - Rootkit Scanner - = -
-= - by [email protected] - = -

Scanning for ADORE version 0.14, 0.24 and 2.0b.
ADORE rootkit NOT DETECTED on this system.

Scanning for KNARK version 0.59.
KNARK rootkit NOT DETECTED on this system.

Ось в принципі і все, що хотілося розповісти сьогодні. Висновок один - адмін повинен бути трохи параноїком, тому що нападник завжди йде на крок попереду. Успіхів.