Виявлення і видалення «троянських коней» в ОС Linux

1. ПРЕВЕНТИВНІ ЗАХОДИ
2. ВИЯВЛЕННЯ «троянського коня»
3. NMAP
4. ІНШІ ІНСТРУМЕНТИ
5. ЗАРАЖЕННЯ ЯДРА LINUX
6. КОМЕРЦІЙНІ ІНСТРУМЕНТИ
7. ВИСНОВКИ
8. Ресурси Internet:

Це ранок видався несподівано насиченим для нашої служби технічної підтримки UNIX: всі клієнти, які розмістили у нас свої сервери Web, як змовившись, просили провести їх перезавантаження, оскільки робота з серверами, як з командного рядка, так і через інтерфейс Web, йшла катастрофічно повільно. Перед виконанням перезавантаження ми вирішили встановити причину неполадок. На жаль, кожен раз при спробі зайти на будь-який сервер Linux через SSH, з'єднання розривалося демоном SSH по тайм-ауту. Одночасно адміністратор спостерігав незвичайне збільшення трафіку через деякі порти комутатора. Незабаром виявилося, що всі проблемні сервери були підключені через вищезгадані порти комутатора. Негайно відключивши ці порти, ми приступили до нашого розслідування.

Після повторного включення портів нам вдалося успішно зайти на сервери по SSH. Виконавши команди ps aux, top і df і не виявивши нічого незвичайного, ми запустили nmap для перегляду відкритих портів. Як правило, у наших клієнтів відкриті порти TCP з номерами 21, 25, 53, 80, 119, 443 і, іноді, 143. Після запуску nmap ми виявили ще три цікавих порту і спробували з'єднатися з кожним з них за допомогою команди telnet. З першими двома не було пов'язано нічого поганого, а ось з'єднання з третім відкрило повний доступ з правами суперкористувача. Після цього ми зрозуміли, що сервери наших клієнтів були зламані.

Основна мета статті полягає не в тому, щоб розповісти, як саме були зламані сервери, а в тому, щоб показати, як зломщики намагалися приховати цей факт від нас і від наших клієнтів. Після проникнення в систему вони впровадили в неї «троянського коня» для подальшого віддаленого входу. Більш того, щоб його присутність в системі не було виявлено, деякі системні файли виявилися підмінені: наприклад, команда / bin / ps була змінена з метою приховування «троянських демонів».

Стаття наочно продемонструє всю важливість прийняття превентивних заходів, а при наявності підозр на присутність у вашій системі «троянського коня» надасть інформацію для його виявлення і усунення в ОС Linux.

ПРЕВЕНТИВНІ ЗАХОДИ

«Троянський кінь» - це програма з прихованими функціями. Виконуючи на перший погляд деякі дозволені дії, насправді вона може видаляти файли, встановлювати віруси або іншого «троянського коня», створювати в системі люки для несанкціонованого доступу і пригнічувати її активність для приховування факту атаки. Ось кілька порад, які допоможуть знизити ризик «троянських» атак.

1. Постійно будьте в курсі новин зі світу інформаційної безпеки.
2. Ніколи не встановлюйте програми "наосліп", навіть з "надійних джерел". Іноді таке джерело сам може не підозрювати про наявність "троянського коня". Наприклад, NAI повідомляло про оновлення до програми BIND, нібито усуває помилку в системі безпеки. Насправді оновлення було "троянцем".
3. Перевіряйте контрольні суми MD5 завантажених з Internet програм і програм із зовнішніх джерел.
4. Ніколи не відкривайте вкладення з листів, якщо ви не впевнені в чистоті намірів їх відправника.
5. З обережністю ставитеся до всього, що запускається з браузера Internet. Аплети Java, програми ActiveX і JavaScript можуть встановлювати "троянців".
6. Намагайтеся, по можливості, входити в систему з правами непривилегированного користувача. Використання облікового запису суперкористувача для виконання повсякденних адміністративних завдань збільшує ймовірність ураження системи.

«Троянських коней» можна виявити за допомогою систем виявлення вторгнень (Intrusion Detection System, IDS). В рамках цієї статті у нас немає можливості вдаватися в деталі функціонування IDS. Багато IDS, такі, як Snort, Prelude і NABOU, прекрасно задокументовані. IDS можуть бути налаштовані на пошук незвичайного вмісту пакетів, що входять і виходять з вашої мережі, або спиратися на інформацію про вже існуючих «троянських конях». наприклад:

alert tcp $ EXTERNAL_NET 31790 -> $ HOME_NET 31789 (msg: "P-1-SCAN trojan hack-a-tack probe"; content: "A"; depth: 1; reference: arachnids, 314; flags: A +; classtype: attempted-recon; sid: 614; rev: 1;)

Це правило дозволить виявити наявність «троянця» Hack? A? Tack, який впроваджується в ПК з ОС Windows 95/98. Його серверна частина працює на зараженій машині Windows і називається expl32.exe. Він перетворює машину Windows в сервер передачі файлів для пошуку інших «троянців» та збору основної інформації про комп'ютер, а також використовується для установки інших «троянських коней» в систему. Правило повідомляє про існування зонда Hack? A? Tack при наявності з'єднання від машини поза мережею (швидше за все, клієнт) з порту TCP або UDP 31790 на машину всередині мережі (ймовірно, сервер) на порт 31789.

Tripwire - інструмент, що відстежує зміни в системних файлах. Він спостерігає за ключовими атрибутами файлів, що не підлягають змінам, включаючи цифровий підпис, розмір і очікувана зміна розміру. Tripwire корисний тільки в якості превентивного заходу в тому випадку, якщо він встановлений в систему до зараження «троянцем». Хоча принципи, за якими функціонує Tripwire, можуть успішно застосовуватися і при самостійному розслідуванні.

ВИЯВЛЕННЯ «троянського коня»

Один з кращих способів виявлення «троянського коня» на машині Linux - самостійне розслідування. Воно може виявитися досить трудомістким, але дозволить уникнути зараження в майбутньому. При виникненні підозр на наявність «троянця» комп'ютер слід відключити від мережі, щоб запобігти подальшим руйнівні дії. Корисно створити архів з деяких програм (наприклад, ps, nmap, fuser, netstat, lsmod, rpm, find, md5sum, cp, mv, kill, chmod, chown і ls) і записати його на дискету або компакт-диск, щоб при необхідності перенести на заражену машину. Якщо у вас немає коштів виявлення вторгнень, їх слід створити за допомогою виконуваних файлів з незараженої комп'ютера. Зловмисники часто підміняють виконувані файли IDS зміненими еквівалентами, так що не користуйтеся цими інструментами до тих пір, поки не будете впевнені в тому, що вони не підмінені і не змінені. Переконайтеся також, що виконувані файли на «чистій» машині тієї ж версії, що і виконувані файли на зараженій, і тільки потім перенесіть їх в новий каталог, названий, наприклад, / toolkit, на зараженій машині.

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

$ / Toolkit / md5sum / toolkit / ps / bin / ps

Це необхідно на випадок, якщо зломщик змінив виконуваний файл команди ps. Результат виведення вищеописаної команди матиме приблизно такий вигляд:

ac0b58050deb21db1ed701277521320b / toolkit / ps ac0b58050deb21db1ed701277521320b / bin / ps

Якщо контрольні суми MD5 збігаються, то, швидше за все, виконуваний файл ps на машині не був заражений. Командою md5sum можна перевірити всі файли з набору засобів і порівняти їх з контрольними сумами файлів, встановлених в системі. Відзначте всі контрольні суми MD5, які не збігаються між собою.

Після перевірки контрольної суми MD5 для ps, цю команду можна запустити для перегляду виконуються процесів в системі. У разі збігу сум MD5 команди ps з вашого набору і команди ps, встановленої в системі, перегляд можна провести шляхом запуску як вашої версії / toolkit / ps, так і версії / bin / ps з системи. Якщо контрольні суми не збігаються, запускайте / toolkit / ps; в іншому випадку отриманий список може не відповідати дійсності. До того ж якщо зломщик справді підмінив виконуваний файл ps, то його запуск може призвести до ще більших руйнувань. Копію списку процесів збережіть в текстовий файл для подальшого вивчення, потім перегляньте список на наявність незвичайних процесів або процесів, які до цього не були запущені в явному вигляді.

Я стикався з ситуаціями, коли «троянський кінь» був присутній в списку процесів, але залишався непоміченим на тлі інших процесів. Наприклад, в списку поряд з кількома процесами httpd може бути присутнім і схоже названий «троянський кінь». У висновку ps нижче процеси з ідентифікаторами PID 16972, 16975, 17333, 17724, 17805, 18360 і 19290 є дійсними процесами httpd Web-сервера Apache. Але зверніть увагу на процес з ідентифікатором PID 32444. У нього схоже ім'я, і ​​його легко пропустити при побіжному перегляді списку. Але при найближчому розгляді цей процес з ім'ям http не є частиною Web-сервера Apache і цілком може бути потрібним «троянцем»:

NMAP

Припускаючи, що «винний» все ще не знайдений, перейдемо до наступної програми - nmap. Сканування зараженої машини на наявність всіх відкритих портів UDP і TCP дозволяє виявити, який порт використовує «троянський кінь». Це може бути зроблено за допомогою наступної команди:

$ / Toolkit / nmap -sU -sS -p 1-65535 localhost

Ось приклад виведення:

Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )

Цікаві порти на localhost.localdomain (127.0.0.1):

(131048 просканованих, але не показаних нижче портів знаходяться в стані «закритий».)

Порт Стан Сервіс Unable to find nmap-services! Resorting to / etc / services 25 / tcp open smtp 53 / tcp open domain 53 / udp open domain 80 / tcp open http 110 / tcp open pop3 111 / tcp open sunrpc 111 / udp open sunrpc 137 / udp open netbios-ns 138 / udp open netbios-dgm 139 / tcp open netbios-ssn 143 / tcp open imap 389 / tcp open ldap 443 / tcp open https 515 / tcp open printer 617 / tcp open unknown 5222 / tcp open unknown 5269 / tcp open unknown 8383 / tcp open unknown 10000 / udp open unknown 19635 / tcp open unknown 35737 / udp open unknown

Nmap намагається автоматично прив'язати номер порту до назви сервісу відповідно до файлом / etc / services, але в разі відсутності чого-небудь схожого повертає значення unknown. Якщо після перевірки виведення nmap вам не вдається пригадати, що будь-який процес повинен прослуховувати 5222, то це можна спробувати з'ясувати за допомогою команди fuser з вашого комплекту засобів.

Для того щоб визначити, який процес звертається до порту з цим номером, виконайте наступне:

$ / Toolkit / fuser -vn tcp 5222

Результатом буде:

USER PID ACCESS COMMAND 5222 / tcp jabber 1918 f .... jabberd jabber 1919 f .... jabberd

Звідси видно, що цією службою був jabber.

Команду fuser можна запустити повторно, щоб дізнатися, який ідентифікатор процесу (PID) асоціюється з підозрілим портом TCP 19635:

$ / Toolkit / fuser -vn tcp 19635

висновком якої буде:

USER PID ACCESS COMMAND 19635 / tcp root 32444 f .... http

Очевидно, що процес під назвою http виконується з ідентифікатором 32444 і слухає порт 19635. Цей процес не входить до складу Web-сервера Apache. Якщо він залишився непоміченим перш, значить, зараз ми точно знаємо, що запущений на машині «троянський кінь» маскується під законні процеси httpd.

Отже, з портом 5222 працює сервер jabber. Можливо, що сервер jabber після атаки не залишився тим же сервером jabber, що і до атаки. Створений хакером «троянець» міг замінити дійсний процес jabberd на процес з тим же ім'ям для роботи на тому ж порту. Для перевірки цілісності файлу jabberd можна використовувати md5sum і порівняти результати обчислення контрольної суми файлу на «чистій» машині і файлу на зараженій. Перш ми робили це для перевірки цілісності файлів в нашому наборі і файлів на зараженому сервері. Інший корисний спосіб (якщо двійковий файл є частиною RPM) - запустити команду rpm з ключем verify. У разі видалення або зміни будь-якого з самого початку включеного в пакет файлу менеджер пакетів Red Hat (Red Hat Package Manager, RPM) повідомить про це. Ми можемо виконати наступну команду для перевірки виконуваного файлу jabberd за умови, що сервер jabber був встановлений з використанням rpm:

$ Rpm -verify jabberd-0.9-1.rpm

Якщо всі файли (включаючи двійковий файл jabberd) є вихідними і не заражені, тоді, швидше за все, ця команда не видасть ніяких результатів. Якщо ж jabberd насправді містить «троянського коня» або був змінений іншим способом, тоді команда rpm повідомить щось схоже на:

S.5 ... T / usr / bin / jabberd

Rpm з ключем verify перевіряє контрольну суму MD5, розмір файлу і права доступу для кожного файлу, що встановлюється з пакета RPM. Наведена вище рядок показує, що розмір файлу (S) змінився, контрольні суми MD5 не збігаються (5) і час модифікації інше (T). Крім S, 5 і T в разі зміни інших атрибутів файлу з'являться додаткові символи.

Локальний перегляд мережевих з'єднань можливий за допомогою програми netstat. Вона застосовується як в поєднанні з nmap, так і замість nmap. Для пошуку зниклих або змінених файлів за допомогою команди find. Залежно від вашого стилю розслідування можна звернутися і до інших програм, але, мені здається, що з завданням виявлення «троянського коня» цілком можуть впоратися кілька широко відомих програм. Додаткові програми в наборі, наприклад mv, cp, chmod і chown, присутні просто для спрощення та економії часу в разі, якщо вихідні програми були змінені або видалені.

ІНШІ ІНСТРУМЕНТИ

Вищеописані дії можуть не привести до бажаних результатів. В такому випадку доведеться «копнути» дещо глибше. Можливо, зломщик встановив «троянського коня», який поки що не виявляє активності на вашій машині. Його запуск, наприклад, міг бути запланований за допомогою cron або at. Щоб з'ясувати це, необхідно переглянути всі файли конфігурації cron і at на предмет їх посередництва у запуску незвичайних програм. Крім того, бажано перевірити сценарії в каталогах cron.daily, cron.hourly і cron.weekly. Відомі випадки, коли «троянець» маскувався під сценарій програми logrotate.

Необхідно також переконатися в чистоті всіх запущених демонів. Наприклад, процес syslogd виявляється скомпрометований, і замість дійсного демона на порту UDP 514 запущений «троянець». Отже, треба перевірити, чи немає змін у всіх файлах і демонів і зберігають вони свою цілісність. Нерідко це стає досить трудомістким заняттям, яке може і не варто витраченого часу і грошей.

Завдання можна полегшити за рахунок використання Red Hat Package Manager з ключем verify яких інших програм з відкритим кодом від сторонніх джерел, призначених як для безпосереднього виявлення «троянця», так і в якості доповнення до наявного комплекту інструментальних засобів. Один з таких інструментів, chkrootkit, може виявити люк в системі, встановлений як частина «троянського коня». Chkrootkit шукає відомі послідовності символів в заражених файлах. Він вміє відшукувати таких «троянців», як Ramen Worm, T0rn rootkit або Ambient? S Rootkit for Linux, і це тільки мала частина. Крім того, виявляє мережеві інтерфейси зі здатністю прийому всіх пакетів (promiscuous mode). Після установки chkrootkit його можна запустити командою:

$ chkrootkit

яка видасть приблизно наступне:

ROOTDIR is '/' Checking 'chfn' ... Not vulnerable Checking 'chsh' ... Not vulnerable Checking 'cron' ... Not vulnerable Checking 'sshd' ... Not vulnerable Checking 'du' ... Not vulnerable Checking 'find' ... Not vulnerable Checking 'fingerd' ... Not vulnerable Checking 'su' ... Not vulnerable Checking 'ifconfig' ... Not vulnerable Checking 'inetd' ... Not vulnerable Checking 'killall'. .. Not vulnerable Checking 'login' ... Not vulnerable Checking 'ls' ... Not vulnerable Checking 'netstat' ... Not vulnerable Checking 'passwd' ... Not vulnerable Checking 'pidof' ... Not vulnerable Checking 'ps' ... Not vulnerable Checking 'rshd' ... Not vulnerable Checking 'syslogd' ... Not vulnerable Checking 'tcpd' ... Not vulnerable Checking 'top' ... Not vulnerable Checking 'telnetd' .. . not vulnerable Checking 'asp' ... not vulnerable Checking 'bindshell' ... not vulnerable Checking 'z2' ... Nothing deleted Checking 'wted' ... Nothing deleted Checking 'sniffer' ... eth0 is not promisc vmnet1 is not promisc Checking 'aliens'. .. No suspect files Searching for sniffer's logs, it may take a while ... Nothing found Searching for t0rn's default files and dirs ... Nothing found Searching for Ambient's rootkit (ark) default files and dirs ... Nothing found Searching for suspicious files and dirs, it may take a while ... /usr/lib/linuxconf/install/gnome/.directory /usr/lib/linuxconf/install/gnome/.order /usr/lib/perl5/5.00503/i386- linux / .packlist /usr/lib/perl5/site_perl/5.005/ i386-linux / auto / MD5 / .packlist /lib/modules/2.2.14-5.0/.rhkmvtag Searching for Ramen Worm files and dirs ... Nothing found Checking 'lkm' ... Nothing detected

ЗАРАЖЕННЯ ЯДРА LINUX

Безпосереднє увагу в статті приділено зараження системних файлів «троянським конем», але він може потрапити і безпосередньо в ядро ​​Linux. Одним з таких відомих «троянців» є KIS Trojan, який був розроблений з метою автоматизації завантаження модуля ядра. Будучи завантаженим, модуль намагався приховати свою присутність і прослуховував мережу, чекаючи інструкцій. Тут не будуть обговорюватися особливості KIS Trojan, але я згадаю про доступні запобіжні засоби. Перш за все, це завантажуваний модуль безпеки (loadable security module, lsm). Будучи завантаженим, lsm не допускає завантаження або вивантаження будь-якого іншого модуля ядра. Інший інструмент - lcap. За допомогою даної утиліти привілейований користувач може відключати функції ядра, в тому числі можливість завантаження і вивантаження модулів. Для пошуку декількох відомих «троянських» модулів ядра можна використовувати chkrootkit. Команда lsmod, колишня частиною chkrootkit, надає список запущених або завантажених модулів і пристосована для виявлення «троянця» шляхом аналізу списку завантажених модулів. Пам'ятайте, що необхідно перевірити цілісність lsmod перед його запуском.

Якщо ви не знайшли нічого незвичайного серед названих модулів, то, можливо, вражені якісь відомі модулі. Перепишіть імена всіх завантажених модулів на аркуш паперу і вручну видаліть їх по одному з ядра командою rmmod. Так як модулі скомпільовані з коду на Сі, то переглянути їх вихідний код не вдасться. У цілісності модулів можна переконатися за допомогою md5sum і порівняння результату з контрольною сумою неушкодженого модуля. Переконайтеся, що версії ядра на зараженій і «чистої» машині збігаються.

КОМЕРЦІЙНІ ІНСТРУМЕНТИ

Комерційні антивірусні і «антітроянскую» програми випускаються такими виробниками, як Sophos, NAI, Norton та Trend. Вони можуть відшукати «троянського коня» і видалити його з системи, але гарантії виявлення саме на вашій системі немає.

ВИСНОВКИ

Єдиний надійний метод позбавлення машини Linux від «троянського коня», в разі якщо не було прийнято превентивних заходів, - повна перевстановлення системи. Знищення існуючих «троянців» успішно виконують комерційні антивірусні програми. Втім, їх можна знайти і видалити вручну. Цей процес досить трудомісткий і не дає гарантії того, що на машині більше не залишилося «троянських коней». Для збільшення шансів на вдале виявлення «троянського коня» я рекомендую застосування проактивних заходів. Серед зломщиків чимало бажаючих випробувати нові та вдосконалені методи злому, і без належної захисту все може закінчитися тим, що вам доведеться встановлювати заново систему з нуля.

Всі процедури, описані тут, застосовувалися на практиці. Деякі клієнти, сервери яких не мали захисту, відмовилися від перевстановлення системи, в цьому випадку ручні процедури виявилися вельми ефективними в процесі знищення «троянських коней».

Річард Паредез - адміністратор UNIX фінансової установи в центрі Манхеттена. З ним можна зв'язатися за адресою: [email protected] .

Ресурси Internet:

http://www.royalty.nu/legends/Troy.html
http://www.tripwire.org/
http://www.chkrootkit.org/