Я думаю о том, чтобы поставить весь свой Linux-сервер под контроль версий с помощью git. Причина в том, что это может быть самый простой способ обнаружить вредоносные модификации / руткиты. Все, что я наивно полагал, необходимо для проверки целостности системы: монтируйте раздел linux каждую неделю или около того с помощью системы аварийного восстановления, проверяйте, не обработан ли репозиторий git, а затем выдавайте статус git для обнаружения любых изменений, внесенных в систему. .
Есть ли какие-либо другие негативные побочные эффекты, помимо очевидной траты дискового пространства?
Это совершенно безумная идея?
Это даже безопасный способ проверки наличия руткитов, поскольку мне, скорее всего, придется как минимум исключить / dev и / proc?
Это «плохая идея» (тм). Помимо всего прочего, ваш репозиторий будет работать медленно, черт возьми, и становиться все хуже, поскольку каждая ревизия сохраняется.
Попробуйте централизованное управление, например, puppet / cfengine / chef. Это сохранит ваши ожидания и вернет неожиданные изменения.
Совместите это с чем-то вроде iwatch, чтобы получать электронные письма о несанкционированных изменениях файлов.
Совместите это с файлами rpm / deb, если необходимо для развертывания пользовательских приложений.
Добавьте что-нибудь вроде rkhunter или chkrootkit время от времени, чтобы получить удовольствие, и все будет хорошо.
Работа выполнена.
Другой вариант - настроить растяжка, это программное обеспечение под лицензией GPL, которое просматривает все важные файлы в вашей системе и определяет, какие из них были изменены способом, который вы определили как неприемлемый. Изменение можно определить так же просто, как mtime, через номер inode, вплоть до криптографически надежных контрольных сумм.
Требуется некоторая настройка и настройка, если вы не хотите получать много отчетов каждую ночь об измененных файлах в /var/run, изменения в файлах клиента DHCP в /etc, и тому подобное, но если вы столкнетесь с этой проблемой, это действительно может быть очень полезно.
База данных свойств файла подписана ключом не известно машине, что дает вам уверенность в том, что ни один инструмент не изменил злонамеренно базу данных или двоичные файлы tripwire. Для полной уверенности вы можете записать копию инструментов и баз данных tripwire на носитель, доступный только для чтения, который может быть установлен на сервере и использован для проверки всех изменений с момента записи диска, если требуется полный криминалистический анализ.
Если вы собираетесь это сделать, очень важно настроить и запустить tripwire до того, как машина будет запущена в производство, иначе вы никогда не сможете быть полностью уверены, что у какого-то злонамеренного пользователя не было возможности заразить машину до этого. был подключен к сети.
Я не думаю, что это сработает, но в качестве эксперимента я хотел бы посмотреть, что произойдет, если вы сделаете это только с папкой / etc. Здесь хранится большая часть информации о конфигурации.
@Sirex уже дал очень хороший ответ, но если вы хотите сделать еще один шаг в области безопасности, лучший способ справиться с этим - сначала предотвратить, а затем обнаружить.
Попробуйте настроить систему с установленным / filesystem только для чтения. Сделайте / tmp отдельным ramfs, смонтированным с параметром noexec, nodev. Чтобы система работала, вам действительно нужно смонтировать / var для чтения и записи. Итак, в / var смонтируйте файловую систему с помощью rw, noexec, nodev и удалите права на запись в / var / tmp (черт возьми, это редко требуется демонам, и это должно быть настраиваемым). Также используйте исправление безопасности для вашего ядра, чтобы еще больше ограничить доступ пользователей к ресурсам, например, попробуйте grsec. Используйте брандмауэр с максимально строгими правилами.
Некоторые дистрибутивы предоставляют обширную документацию по усилению защиты системы. Например:
Я думаю, это хорошая идея - проанализировать изменения, которые инструмент вносит в вашу систему:
... Удалить виртуальную машину
Вам нужно будет добавить много папок в .gitignore файл хоть вроде proc и т. д.
В ситуациях, когда вы просто заинтересованы в том, чтобы определенные папки во всей файловой системе находились под контролем версий, может работать следующий подход:
Сначала создайте репозиторий Git на / уровень:
$ cd /
# git init
Затем создайте /.gitignore который добавляет в белый список только определенные папки, например только в белый список /path/to/versioned/config/folder/ (на основе https://stackoverflow.com/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/) для управления версиями этой конкретной папки, поскольку она более специализирована для этой цели (например, она автоматически фиксируется после установки пакетов).