Як перевірити виконуваний файл, щоб переконатися, що він не є шкідливим?

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

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

Я б не проти чогось із графічним інтерфейсом.

це інструмент або, можливо, віртуальна машина для запуску виконуваного файлу всередині нього

Так, це називається віртуалізацією додатків .

LXC (Linux Containers) - це поширений інструмент для його налаштування. Це дозволяє налаштувати повністю відокремлену мережу для цього додатка, і це "пісочниці" це у якусь віртуальну машину, подібно до chroot. Це в основному з метою безпеки ("в'язниця"), а не насправді для аудиту.

Я думаю, що це трохи поза сферою питання, щоб пояснити повний контейнер LXC, а також як його точно перевірити. Нижче трохи нижче про те, як розпочати роботу.

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

Це можна досягти за допомогою, straceі я задав те саме питання в Unix & Linux:

• Як я можу відстежувати відкриті файли процесу в режимі реального часу? (також охоплює мережу)

Як там відповіли , це зводиться до принципу

strace -t -e trace=open,close,read,getdents,write,connect,accept command-here

Важливо: як тільки ви побачите, що це відбувається, шкода вже відбулася.

Контейнер додатків LXC

З цієї статті . Це зводиться до:

1. lxc-macvlan.conf файл конфігурації:

   # example as found on /usr/share/doc/lxc/examples/lxc-macvlan.conf
   # Container with network virtualized using the macvlan device driver
   lxc.utsname = alpha
   lxc.network.type = macvlan
   lxc.network.flags = up
   lxc.network.link = eth0 # or eth2 or any of your NICs
   lxc.network.hwaddr = 4a:49:43:49:79:bd
   lxc.network.ipv4 = 0.0.0.0/24
   

2. Почніть його за допомогою lxc-execute:

   sudo lxc-execute -n bash-test2 -f lxc-macvlan.conf /bin/bash
   

Зауважте, що LXC пропонує як контейнери системного, так і застосування. Ви шукаєте контейнери для додатків тут.

Що ви шукаєте - це інструмент, який показує, як програма взаємодіє із системою (точніше, з ядром). Програми взаємодіють із системою за допомогою системних дзвінків. Прикладами системних викликів є:

• open - використовується для відкриття файлу;
• readі write- використовується для читання / запису з / до дескриптора файлу;
• connect - використовується для підключення розетки до однорангової;
• багато, багато інших (див. man syscalls).

Справа в тому, що систематичні дзвінки можна простежити за допомогою ptrace(2). Отже, ви в основному шукаєте інструменти, побудовані навколо ptrace. Одним із таких інструментів є strace(1)термінальна програма, яка приймає команду як аргумент і виводить:

• системні дзвінки, що викликає програма;
• аргументи, які використовуються для створення системних викликів;
• результат системних викликів.

Вихід проводиться на C-манері. Ось приклад:

$ strace cat test
execve("/bin/cat", ["cat", "test"], [/* 55 vars */]) = 0
/* ... */
open("test", O_RDONLY)                 = 3
/* ... */
read(3, "hello\n", 32768)               = 6
write(1, "hello\n", 6)                  = 6
read(3, "", 32768)                      = 0
/* ... */

Там ви бачите, що cat testвідкриваєте файл з назвою test, читаєте його вміст ( hello) та розміщуєте його на стандартному виході.

straceможе отримати багато результатів, тому не забудьте прочитати його man page ( man strace), особливо документацію -eвиходу, яка дозволить вам бачити тільки цікаві вам syscalls.

На жаль, мені не відомі графічні чи зручні у використанні альтернативи. Якщо ви хочете їх шукати, ptraceмає бути одним із ключових слів пошуку.

Щодо ізоляції, там багато технологій. Найбільш використовуються Chroots, контейнери Linux (які наразі знаходяться в стадії розробки та неповні), віртуалізація та паравіртуалізація програмного забезпечення. Однак це занадто велика тема для обговорення. Я б запропонував відкрити нове запитання, якщо ви хочете отримати більше деталей.

Погляньте на AppArmor . Ви можете додати обмежений профіль для виконуваного файлу і перевести його в режим "скарги", де дії будуть дозволені, але вхід у систему, що, на мою думку, відповідає вашим вимогам.

Але зауважте, що цього насправді недостатньо. Розумний шкідливий бінарний файл може виявити, що він знаходиться під спостереженням, і не виконувати шкідливих дій, за винятком випадків, коли його не спостерігають.

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

Як ви визначили, віртуальній машині було б краще забезпечити ізоляцію, особливо якщо у вас є підстави вважати, що виконуваний файл в першу чергу зловмисний. Але навіть це не є досконалим, оскільки вразливості платформи віртуалізації (як апаратного, так і програмного забезпечення) можуть використовуватися шкідливим кодом, щоб вибухнути. Ось приклад реальної вразливості щодо віртуалізації у світі: http://www.kb.cert.org/vuls/id/649219

Ви можете створити оснащення .

Знімки "обмежені в ОС та інших додатках через механізми захисту, але можуть обмінюватися вмістом і функціями з іншими знімками відповідно до тонко деталізованої політики, керованої користувачем та за замовчуванням в ОС". (від http://snapcraft.io/docs/snaps/intro )

Вони забезпечують подальшу ізоляцію, крім AppArmor, наприклад, використовуючи також seccomp .

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

Дякую, відповіді були дуже корисні ...

Я також виявив це: https://downloads.cuckoosandbox.org/docs/

Це дуже цікавий інструмент для аналізу зловмисного програмного забезпечення, поки він сидить у віртуальній машині