Поставлення цілого сервера Linux під управління джерелом (git)

Я думаю про те, щоб увесь сервер Linux був під контролем версій за допомогою git. Причиною цього є те, що це може бути найпростішим способом виявлення шкідливих модифікацій / руткітів. Все, що я б наївно вважав необхідним, щоб перевірити цілісність системи: монтуйте розділ Linux щотижня або близько того, використовуючи рятувальну систему, перевіряйте, чи зберігається сховище git, і тоді видайте статус git, щоб виявити будь-які зміни, внесені до системи .

Крім очевидних відходів дискового простору, чи є інші негативні побічні ефекти?

Це абсолютно божевільна ідея?

Це навіть безпечний спосіб перевірити наявність руткітів, оскільки мені, швидше за все, доведеться принаймні виключити / dev та / proc?

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

Спробуйте централізоване управління, як лялька / cfengine / шеф. Це збереже речі, як ви очікуєте, і поверне несподівані зміни.

Поєднайте це з чимось на зразок iwatch, щоб отримувати електронні листи про несанкціоновані зміни файлів.

Комбінуйте це далі з файлами rpm / deb, якщо потрібно, щоб розгорнути спеціальні програми.

Киньте щось на кшталт rkhunter або chkrootkit час від часу для ударів, і вам слід добре піти.

Робота виконана.

Іншою альтернативою є налаштування трипровідного провідного програмного забезпечення, яке є програмним забезпеченням GPL'ed , яке простежує всі важливі файли вашої системи та визначає, які змінилися способами, які ви визначили як неприйнятні. Зміни можна визначити просто як mtime, через номер inode, аж до криптографічно сильних контрольних сум.

Потрібні певні налаштування та налаштування, якщо ви не хочете щовечора отримувати безліч звітів про змінені файли /var/run, про зміни в клієнтських файлах DHCP /etcтощо, але якщо ви дійдете до цієї проблеми, це може бути дуже корисно.

База даних властивостей файлу підписаний за допомогою ключа НЕ відомої машини, яка допоможе вам бути впевнені , що ні один інструмент не зловмисно змінили базу даних або натяжна виконавчі файли. Для повної впевненості ви можете записати копію інструментів і баз даних тривимірних даних на носій, доступний лише для читання, який можна встановити на сервері та використовувати для перевірки всіх змін після запису диску, якщо потрібен повний криміналістичний аналіз.

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

Я не думаю, що це, ймовірно, спрацює, але в якості експерименту я хотів би побачити, що станеться, якщо ви це зробите лише з папкою / etc. Саме тут зберігається більшість інформації про конфігурацію.

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

Спробуйте налаштувати систему за допомогою файлової системи, встановленої лише для читання. Зробіть / tmp окремим рамками, змонтованим з опцією noexec, nodev. Щоб система працювала, вам дійсно потрібно лише / var для монтажу читання-запису. Отже, під / var монтуємо fs з rw, noexec, nodev та видаляємо дозволи на запис в / var / tmp (afaik, демони це рідко потрібно, і це має бути налаштовано). Також використовуйте патч безпеки для свого ядра для подальшого обмеження доступу користувачів до ресурсів, спробуйте, наприклад, grsec. Використовуйте брандмауер із максимально обмежуючими правилами.

Деякі дистрибутиви надають велику документацію щодо загартовування системи. Наприклад:

• Забезпечення посібника Debian
• Загартовування Debian Wiki

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

1. встановити голий Linux у віртуальній машині
2. ініціалізувати кореневу кишку
3. встановіть інструмент, який ви хочете проаналізувати
4. переглянути всі зміни, зроблені у вашій системі

... Видаліть VM

Вам доведеться додати багато .gitignore файлів у файл, хоча, як proc тощо.

У ситуаціях, коли ви просто зацікавлені утримуванні певних папок у всій файловій системі під контролем версій, може працювати наступний підхід:

Спочатку створіть сховище Git на /рівні:

$ cd /
# git init

Потім створіть у /.gitignoreцьому списку лише певні папки, наприклад лише в білий список /path/to/versioned/config/folder/(на основі /programming//a/11018557/320594 ):

/*
!/path/
/path/*
!/path/to/
/path/to/*
!/path/to/versioned/
/path/to/versioned/*
!/path/to/versioned/config/
/path/to/versioned/config/*
!/path/to/versioned/config/folder/
!/.gitignore

Потім створіть першу комісію:

# git add -A
# git commit -m "Initial commit"

А потім додайте додаткові папки, які ви хочете під контролем версій на вимогу.

PS:

На додаток до попереднього методу, якщо вам потрібно тримати / etc / під контролем версій, ви можете скористатися etckeeper( https://etckeeper.branchable.com/ ) для версії цієї конкретної папки, оскільки вона спеціалізована для цієї мети ( наприклад, він автоматично здійснюється після встановлення пакунків).