Poddanie całego serwera linux kontroli źródła (git)

Zastanawiam się nad poddaniem całego serwera linux kontroli wersji za pomocą git. Jest to spowodowane tym, że może to być najłatwiejszy sposób na wykrycie złośliwych modyfikacji / rootkitów. Wszystko, co naiwnie uważam za konieczne, aby sprawdzić integralność systemu: montuj partycję linux co tydzień za pomocą systemu ratunkowego, sprawdź, czy repozytorium git nadal nie jest ulepszane, a następnie nadaj status git, aby wykryć wszelkie zmiany wprowadzone w systemie .

Czy oprócz oczywistych marnotrawstwa miejsca na dysku są jeszcze jakieś negatywne skutki uboczne?

Czy to całkowicie szalony pomysł?

Czy to nawet bezpieczny sposób na sprawdzenie przed rootkitami, ponieważ najprawdopodobniej musiałbym przynajmniej wykluczyć / dev i / proc?

To „zły pomysł” (tm). Oprócz wszystkich innych, twoje repozytorium będzie działało wolno, jak tylko do cholery, i będzie się pogarszać wraz z każdą aktualizacją.

Spróbuj scentralizowanego zarządzania, takiego jak marionetka / cfengine / szef kuchni. Pozwoli to zachować wszystko zgodnie z oczekiwaniami i cofnąć nieoczekiwane zmiany.

Połącz to z czymś takim jak iwatch, aby otrzymywać e-maile z nieautoryzowanymi zmianami plików.

W razie potrzeby połącz to z plikami rpm / deb, aby uruchomić niestandardowe aplikacje.

Od czasu do czasu wrzuć coś takiego jak rkhunter lub chkrootkit, by zacząć kopać i powinieneś być gotowy.

Zadanie wykonane.

Inną alternatywą jest skonfigurowanie tripwire , czyli oprogramowania GPL, które przegląda wszystkie ważne pliki w twoim systemie i określa, które zmieniły się w sposób, który określiłeś jako niedopuszczalny. Zmianę można zdefiniować jako mtime, poprzez numer i-węzła, aż do kryptograficznie silnych sum kontrolnych.

Trwa konfiguracja i dostrajanie, jeśli nie chcesz co noc otrzymywać wielu raportów o /var/runzmianach w plikach , zmianach w plikach klienta DHCP /etcitp., Ale jeśli napotkasz takie problemy, może to być naprawdę bardzo pomocny.

Baza właściwości pliku jest podpisany za pomocą klucza nie wiadomo, maszyny, dzięki której można mieć pewność, że żadne narzędzie złośliwie zmienił bazy danych lub binaria Tripwire. Aby uzyskać całkowitą pewność, możesz wypalić kopię narzędzi tripwire i baz danych na nośniku tylko do odczytu, który można zamontować na serwerze i użyć do zweryfikowania wszystkich zmian od czasu nagrania dysku, jeśli konieczna jest pełna analiza kryminalistyczna.

Jeśli masz zamiar to zrobić, bardzo ważne jest skonfigurowanie i uruchomienie tripwire przed wdrożeniem maszyny do produkcji, lub nigdy nie możesz być całkowicie pewien, że jakiś złośliwy użytkownik nie miał szansy zainfekować maszyny przed nią był tripwired.

Nie sądzę, że to prawdopodobnie zadziała, ale jako eksperyment chciałbym zobaczyć, co się stanie, jeśli zrobisz to tylko z folderem / etc. Tam przechowywana jest większość informacji o konfiguracji.

@Sirex podał już bardzo dobrą odpowiedź, ale jeśli chcesz zrobić krok dalej w kwestii bezpieczeństwa, najlepszym sposobem na poradzenie sobie z tym jest najpierw zapobieganie, a następnie wykrywanie.

Spróbuj skonfigurować system z / system plików zamontowanym tylko do odczytu. Uczyń / tmp oddzielnym ramfsem zamontowanym z opcją noexec, nodev. Aby system działał, tak naprawdę potrzebujesz tylko / var do zamontowania odczytu i zapisu. Więc pod / var zamontuj fs z rw, noexec, nodev i usuń uprawnienia do zapisu do / var / tmp (afaik, rzadko jest potrzebny demonom i powinien być konfigurowalny). Użyj również poprawki bezpieczeństwa dla swojego jądra, aby dodatkowo ograniczyć dostęp użytkowników do zasobów, spróbuj na przykład grsec. Użyj zapory ogniowej z możliwie najbardziej restrykcyjnymi regułami.

Niektóre dystrybucje zawierają obszerną dokumentację dotyczącą hartowania systemu. Na przykład:

• Zabezpieczanie Podręcznika Debiana
• Hardening Debian Wiki

Myślę, że dobrym pomysłem jest przeanalizowanie zmian, które narzędzie wprowadza w twoim systemie:

1. zainstaluj goły system Linux na maszynie wirtualnej
2. zainicjuj root git
3. zainstaluj narzędzie, które chcesz przeanalizować
4. zobacz wszystkie zmiany w rzucie wykonane w twoim systemie

... Usuń maszynę wirtualną

Trzeba jednak dodać wiele folderów do .gitignore pliku, takich jak proc itp.

W sytuacjach, w których chcesz tylko utrzymać określone foldery w całym systemie plików pod kontrolą wersji, może działać następujące podejście:

Najpierw utwórz repozytorium Git na /poziomie:

$ cd /
# git init

Następnie utwórz listę, /.gitignorektóra ma tylko niektóre foldery, na przykład tylko na białej liście /path/to/versioned/config/folder/(na podstawie /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

Następnie utwórz pierwsze zatwierdzenie:

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

A następnie dodaj dodatkowe foldery, które chcesz kontrolować na żądanie.

PS:

Oprócz poprzedniej metody, jeśli chcesz zachować / etc / pod kontrolą wersji, możesz użyć etckeeper( https://etckeeper.branchable.com/ ) do wersjonowania tego konkretnego folderu, ponieważ jest on bardziej wyspecjalizowany do tego celu ( np. uruchamia się automatycznie po zainstalowaniu pakietów).