Pytanie wydaje mi się "w miarę proste" i pewnie oczekiwano także prostej odpowiedzi.
Ale temat bezpieczeństwa systemu jest trochę bardziej rozległy.
Jeśli zanudzam to proszę pominąć mój post ...
Więc gdyby kogoś interesował trochę szerszy zakres tematu to polecam jeszcze trochę poszukać i poczytać, np.
1. Czy skompilowany plik binarny odzwierciedla kod źródłowy?
2. Czy repozytorium główne jest identyczne z innymi repozytoriami?
3. Czy nie dochodzi np. oszukania pakietu w trakcie przesyłania pakietu.
Ad. 1. Czy skompilowany plik binarny odzwierciedla kod źródłowy?
Chyba najlepiej jest to opowiedziane w temacie " Reproducible builds "
https://www.youtube.com/watch?v=JmHRfT9MeiA (https://www.youtube.com/watch?v=JmHRfT9MeiA)
Ad. 2. Czy repozytorium główne jest identyczne z innymi repozytoriami?
Nie posiadam na ten temat wiedzy jak działa system Debian. Ale wspomniałem że pliki można pobrać i zweryfikować bit po bicie.
Znalazłem taki trochę pomocny temat
https://serverfault.com/questions/322518/can-dpkg-verify-files-from-an-installed-package (https://serverfault.com/questions/322518/can-dpkg-verify-files-from-an-installed-package)
oraz ciekawą informacje w https://www.commandlinux.com/man-page/man8/apt-secure.8.html
W linku niżej są linki np. do dokumentacji Debiana https://www.debian.org/doc/manuals/securing-debian-howto/ch7
Przykładowo mogę sprawdzić plik ls na Mincie. ( pomijając że powinienem to zrobić np. z live-cd )
# locate ls | grep "bin/ls"$
/bin/ls
/usr/lib/klibc/bin/ls
## Sam sie zdziwiłem ze mam dwa pliki ls w systemie :D Wiec dla pewności sprawdziłem który plik uruchamiam.
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
## Dla pewności sprawdziłem także na koncie użytkownika, więc wpisując ls w terminalu wykonuję komendę tylko /bin/ls
# dpkg -S /bin/ls
coreutils: /bin/ls
# dpkg -s coreutils
Package: coreutils
...
Architecture: amd64
Version: 8.28-1ubuntu1
...
## Teraz wiem ze komenda pochodzi z pakietu coreutils
## W linku wyżej wspomniana jest ścieżka /var/lib/dpkg/info/
# ls /var/lib/dpkg/info/ | grep ^coreutils
coreutils.list
coreutils.md5sums
coreutils.postinst
coreutils.postrm
# cat /var/lib/dpkg/info/coreutils.md5sums
749bda6cb12341b7c83c5bb45579201a bin/cat
...
931606baaa7a2b4ef61198406f8fc3f4 bin/ls
...
## Czyli mam w systemie listę plików i ich hash-e (tylko md5).
## Nowsze algorytmy znalazłem tylko samych pakietów, w nieskompresowanych bazach danych w ścieżce /var/lib/apt/lists/ (SHA1, SHA256)
## o czym wspomina inny link
$ grep -ri "Package: coreutils" /var/lib/apt/lists/
...
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_main_binary-amd64_Packages:Package: coreutils
## Choć to nie sugeruje na 100% linku, to znalazłem podobieństwo do http://archive.ubuntu.com/ubuntu/dists/bionic/main/binary-amd64/
# grep -A18 "Package: coreutils" /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_main_binary-amd64_Packages
Package: coreutils
...
Filename: pool/main/c/coreutils/coreutils_8.28-1ubuntu1_amd64.deb
Size: 1230832
MD5sum: 7d95d8dbaca7e89694e63ea4aa907c55
SHA1: 297d10f91608486816dddfa439a308bb9e3361c8
SHA256: 24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f
## Pobieram
$ curl -O http://archive.ubuntu.com/ubuntu/pool/main/c/coreutils/coreutils_8.28-1ubuntu1_amd64.deb
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1201k 100 1201k 0 0 2013k 0 --:--:-- --:--:-- --:--:-- 2010k
## Moze warto sprawdzic pobrany, czego wczesniej nie zrobilem, w tym celu musze stworzyc hash z pliku
sha256sum coreutils_8.28-1ubuntu1_amd64.deb
24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f coreutils_8.28-1ubuntu1_amd64.deb
## I porównać ten hash z hashem z tym znalezionym w systemie
$ [[ 24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f == 24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f ]] && echo OK || echo NOT
OK
## *Rozpakowuje plik (sprawdzilem wczesniej gdzie on jest)
$ ar vx coreutils_8.28-1ubuntu1_amd64.deb
$ tar -xf data.tar.xz "./bin/ls"
Sprawdzam md5
$ md5sum ./bin/ls
931606baaa7a2b4ef61198406f8fc3f4 ./bin/ls
## *Info: " ./bin/ls " to mój rozpakowany plik ls
## *Info: Skoro pobraliśmy pakiet, to możemy zamiast md5 użyć dowolnie inny algorytm np. sha256. Ja niżej użyłem md5
## Generujemy dla /bin/ls
$ md5sum /bin/ls
931606baaa7a2b4ef61198406f8fc3f4 /bin/ls
## Porownalem oba hashe korzystajac z basha
$ [[ 931606baaa7a2b4ef61198406f8fc3f4 == 931606baaa7a2b4ef61198406f8fc3f4 ]] && echo OK || echo "sa nie jednakowe"
OK
## Być może nie musiałem pobierać paczki, ale nie wiem czy i gdzie są sumy md5 plików w repozytorium.
## Gdy chcę porównać pliki ...
## Niżej ( cmp - compare two files byte by byte / diff - compare files line by line )
## INFO: użyłem komendy diff w przykładzie, ale zasadniczo bardziej polecam cmp.
$ cmp /bin/ls /home/user/bin/ls
$
$ diff -s /bin/ls /home/user/bin/ls
Pliki /bin/ls i /home/user/bin/ls są identyczne
Czy klucz GPG zapewnia większe bezpieczeństwo?
Nie mam pewności. Może w internecie będzie coś więcej na ten temat.
Może dłuższy opis lub doklejenie klucza lub czegoś innego może zwiększyć ilość kolizji o jeden bit by ułatwić wstrzyknięcie bardziej złośliwego kodu.
Równie dobrze może przypadkowo utrudnić znalezienie idealnego miejsca na edycję kodu.
Na pewno także suma bitów musi się zgadzać.
Warto poczytać o kolizjach i sprawdzić przykładowo czy suma kontrolna przykładowego pakietu zgadza się z tym podanym w samym pakiecie
oraz może na jakimś przykładzie z bardzo słabym algorytmem.
Ad. 3. Czy nie dochodzi np. do oszukania pakietu w trakcie przesyłania pakietu?
O bezpieczeństwie przesyłania paczek można dowiedzieć się także czytając o błędzie który kiedyś wystąpił
https://thehackernews.com/2019/01/linux-apt-http-hacking.html
oraz https://whydoesaptnotusehttps.com/
Edit: Dla lepszej informacji odrobinę poprawiłem przykład z Mint-em.
Edit.
Zapomniałem tez wspomnieć że można tez poczytać
- o błędach sprzętowych ( np. Spectre, Foreshadow, SPOILER, ZombieLoad, RAMBleed, SWAPGS, NetCAT, TPM-Fail, Meltdown, ...)
- o CVE i błędach w oprogramowaniu ( np. Escalation of Privilege, Denial of Service, Information Disclosure, buffer overflow, integer overflow, ... )
No bo np. jeśli podejrzewamy, że jest coś nie tak to mogli byśmy bacznie obserwować ruch/port/pid i zobaczyć, czy podejrzany proces nawiązywał jakieś połączanie do serwera zewnętrznego.
Troszkę się tym też ostatnio interesuje. I mogę odrobinę napisać aczkolwiek nie wiem wszystkiego.
1. Generalnie potrzebujesz zainstalować lub stworzyć piaskownicę / sandbox.
I tutaj chcę jeszcze jedno napisać.
Jeśli uważam że komenda /bin/ls jest zainfekowana, to równie dobrze mogę przypuszczać że
ktoś lub coś miało dostęp do dowolnego pliku w systemie.
Uważam że większy sens jest blokowanie / nadzorowanie uruchamiania aplikacji innych niż systemowych,
czyli takich które domyślnie można zapisać np. w /tmp , /home/user/ i uruchomić.
Aczkolwiek fajnie by było nadzorować wszystkie aplikacje zarówno systemowe, jak i od razu pobrane.
- Przykłady piaskownic to np. Firejail , AppArmor. To co mnie się rzuciło w oczy to że jedna z nich przy uruchomieniu systemu próbuje ładować gotowe ustawienia,
co wydaje mi się zbędne jeśli chcę śledzić wszystkie aplikacje jednakowo. ( może coś się zmieniło, nie wiem )
- " Prosty sandbox "
Pierwszy sposób: https://wiki.gentoo.org/wiki/Simple_sandbox
Drugi sposób:
https://www.cyberciti.biz/faq/debian-ubuntu-restricting-ssh-user-session-to-a-directory-chrooted-jail/
https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/
- Możesz też poczytać o SELinux https://www.linux.com/tutorials/run-applications-secure-sandboxes-selinux/
2. Zapora iptables.
Iptables pozwala na blokowanie, logowanie i akceptowanie połączeń.
W jednym z linków jest wspomniane o module owner
https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-7.html
https://www.crybit.com/block-incoming-outgoing-network-access/
Sama dokumentacja wspomina krenela 2.4. Spotkałem się z informacją że może być problem ze znalezieniem tego modułu lub w pełni wykorzystaniem ze względu na jego słabą skuteczność.
Aczkolwiek ciężko mi konkretnie tą informacje teraz znaleźć.
3. Problemy z komendami.
Komendy pozwalają na wiele, ale nie które z nich nie działają w czasie rzeczywistym lub ciężko uchwycić zmianę
np. jeśli będę chciał uchwycić nazwę pliku używanego przez dany proces lub wyłapać pakiet internetowy jakąś komendą,
to ta nazwa / informacja może przelecieć szybciej niż będę wstanie wyłapać to innym programem, dlatego istotne jest współpracowanie z kernelem (chyba) aby się tak nie stało. ( albo używać po prostu lepszych komend lub innego sposobu )
Np. użycie jednej komendy pozwala mi wykryć jakiś proces, ale czas procesu może być zbyt krótki zanim użyje/ przefiltruje wynik przy pomocy grep i spróbuje użyć innej komendy.
4. Problem z kernelem.
Polecam poczytać o komendach nice and renice , ulimit , nproc.
Problem jaki spotkałem to np. że mogę zatrzymać forkbomb zrobioną przez aplikacje ale nie potrafię zalogować tego zdarzenia.
Podobno jest to możliwe z kernelem grsecurity lub jakimś patchem.
Bardzo fajną rzeczą związaną z kernelem jest także inotifywait / inotifywatch
Dzięki tej aplikacji można nadzorować czy jakaś aplikacja nam nie otworzyła lub zmodyfikowała dany plik bez zbędnego obciążania systemu.
I dzięki aplikacji notify-send możemy na pulpicie wyświetlić komunikat że jakiś program próbuje coś robić z naszym obserwowanym plikiem.
5. Problem z plikami konfiguracyjnymi i zmiennymi środowiskowymi.
Problem jest taki że znajdują się one w katalogu domowym gdzie możemy je modyfikować.
Przykład takiego przypadku https://www.zdnet.com/article/kde-rips-out-ability-for-kconfig-to-run-shell-code/
Środowisko KDE automatycznie wyszukiwało ikonki do pliku, ale przy okazji jeśli był to skrót to można było tam dodać własną komendę np. instalującego wirusa.
Efekt był taki, że wystarczyło pobrać plik aby system wykonał automatycznie komendy z tego pliku bez naszej wiedzy.
Inny przykład z bash-em.
Wystarczy podmienić zmienną środowiskową $PATH aby przy wpisaniu komendy ls
uruchamiało się /home/user/ls zamiast /bin/ls.
Owy nowy program może też być uruchamiany z plików lokalnych np. ~/.profile , ~/.bashrc
https://wiki-dev.bash-hackers.org/scripting/bashbehaviour
https://access.redhat.com/solutions/65822
Można też próbować uruchomić program w raz ze startem środowiska graficznego np. ~/.config/autostart/
Dlatego jak widzę np. antywirusa który nie sprawdza tak podstawowych rzeczy i jeszcze unika sprawdzić pliku systemowego, to jestem załamany.
Edit
Odnośnie zmiennych warto też przeczytać np. o rbash , " Restricted Linux Shell Escaping Techniques ".
Edit
Możesz jeszcze przeczytać o systemd-run ProtectSystem , aczkolwiek musisz mieć świadomość że nie każdy system używa systemd.
https://endocode.com/blog/2016/11/04/new-sandbox-features-features-in-systemd/
Edit
Gdybyś kiedyś się nudził :D
to odnośnie kernela możesz jeszcze poczytać o ( ewentualnie zatrudnij syntezator mowy do czytania np. google translatora xD )
" Kernel Page Table Isolation " , " Forcefully Unmap Complete Kernel With Interrupt Trampolines "
" Linux Kernel Runtime Guard " https://zaufanatrzeciastrona.pl/post/linux-kernel-runtime-guard-ochrona-przed-jeszcze-nieznanymi-exploitami/
" Kernel Self Protection Project " https://linux-magazine.pl/lm171/na-strazy-kernela-projekt-kernel-selfprotection-zamierza-podniesc-bezpieczenstwo-linuksa-422.html