Security (Polski)
Ten artykuł zawiera zalecenia i najlepsze praktyki dotyczące utwardzania systemu Arch Linux.
Koncepcje
- Możliwe jest zaostrzenie zabezpieczeń do tego stopnia, że system jest nieużyteczny. Bezpieczeństwo i wygoda muszą być zrównoważone. Sztuką jest stworzenie bezpiecznego i użytecznego systemu.
- Największym zagrożeniem jest i zawsze będzie użytkownik.
- Zasada najmniejszego przywileju: Każda część systemu powinna mieć dostęp tylko do tego, co jest ściśle wymagane i nic więcej.
- Obrona w głąb: Bezpieczeństwo działa lepiej w niezależnych warstwach. Gdy jedna warstwa zostanie naruszona, inna powinna zatrzymać atak.
- Bądź trochę paranoiczny i podejrzliwy. Jeśli coś brzmi zbyt pięknie, aby mogło być prawdziwe, to prawdopodobnie tak jest!
- Nigdy nie możesz sprawić, aby system był w 100% bezpieczny, nawet jeśli odłączysz maszynę z sieci, wyłączysz ją, zamkniesz w sejfie, zalejesz w betonie i nigdy jej nie użyjesz.
- Przygotuj się na porażkę. Stwórz plan z wyprzedzeniem, którego będziesz przestrzegać, gdy twoje zabezpieczenia zostaną złamane.
Hasła
Hasła są kluczem do bezpieczeństwa systemu. Zabezpieczają konta użytkowników, zaszyfrowane systemy plików, oraz klucze SSH/GPG. Są one głównym sposobem, w jaki komputer decyduje się zaufać osobie, która go używa, więc duża część bezpieczeństwa polega tylko na wybieraniu bezpiecznych haseł i ich ochronie.
Różnica pomiędzy Password a Passphrase
Może być ważne podkreślenie różnicy pomiędzy tymi słowami, gdyż w języku polskim oba tłumaczą się na hasło.
- Password jest definiowany, jako ciąg znaków (liter, cyfr i innych symboli) służący do uwierzytelniania tożsamości lub weryfikacji uprawnień dostępu. W dalszej części nazywany hasłem.
- Passphrase jest definiowany, jako łatwa do zapamiętania tajemnica składająca się z sekwencji słów lub innego tekstu, którego używa osoba ubiegająca się o dostęp w celu uwierzytelnienia swojej tożsamości. W dalszej części nazywany hasłem frazy.
W skrócie: ważne jest, aby zapamiętać, że password to ciąg znaków 8&YIjth718h!&2es@Fb!+[whR, które zazwyczaj są trudne do zapamiętania przez człowieka, natomiast passphrase to ciąg słów Urwane-Różnorodne-Pieczenie-Śmieciarz-Czekolada2, przez co jest dłuższe, ale łatwiejsze do zapamiętania.
Wybór bezpiecznych haseł
Hasła muszą być wystarczająco złożone, aby nie można było ich łatwo odgadnąć, np. na podstawie informacji osobistych, lub aby nie zostały złamane przy użyciu metod takich jak socjotechnika lub ataki brute-force. Siła hasła zależy głównie od jego długości i losowości. W kryptografii jakość hasła jest często określana jako jego entropia.
Niebezpieczne hasła to takie, które zawierają lub wykorzystują jako podstawę przed zastąpieniem/zmianą:
- Dane pozwalające na identyfikację (np. imię twojego psa, data urodzenia, kod pocztowy/kierunkowy, ulubiona gra wideo)
- Proste podstawienia znaków w słowach (np.
$mu7n4k0t3k), ponieważ współczesne ataki słownikowe z łatwością sobie z nimi radzą. - Słowa bazowe (rdzenie) lub pospolite ciągi znaków, po których następują lub które poprzedzają dodane liczby, symbole lub znaki (np.
Hasło123%, lubQwedsazxc123). - Pospolite frazy lub krótkie ciągi powszechnie używanych słów słownikowych (np.
żebyniczegoniebyło), w tym z podstawieniem znaków (np.Ż3byN!cz3g0n!3był0). (Patrz Diceware poniżej, by sprawdzić, kiedy kombinacja słów słownikowych może być bezpieczna). - Którekolwiek z najczęściej używanych haseł
Najlepszym wyborem dla hasła jest coś długiego (im dłuższe, tym lepsze) i generowanego z losowego źródła. Ważne jest, aby używać długiego hasła. Słabe algorytmy haszujące pozwalają na złamanie hasza 8-znakowego hasła w zaledwie kilka godzin. CERT zaleca przynajmniej 14 znakowe hasło, ale NIST zaleca przynajmniej 15 znakowe, jeśli to jedyny składnik dla większej ilości składników pozwala na 8.
Narzędzia takie jak pwgen lub apgAUR pozwalają generować losowe hasła. Jednak takie hasła mogą być trudne do zapamiętania. Jedną z technik zapamiętywania (dla tych często wpisywanych) jest wygenerowanie długiego hasła i zapamiętanie minimalnie bezpiecznej liczby znaków, tymczasowo zapisując pełny wygenerowany ciąg znaków. Z czasem zwiększaj liczbę wpisywanych znaków, aż hasło zostanie zakorzenione w pamięci mięśniowej i nie będzie musiało być świadomie zapamiętywane. Ta technika jest trudniejsza, ale może zapewnić pewność, że hasło nie pojawi się w listach słów ani w "inteligentnych" atakach brute-force, które łączą słowa i zastępują znaki.
Oprócz zarządzania hasłami, keepassxc oferuje generowanie haseł / haseł fraz.
Jedna z technik zapamiętywania hasła polega na użyciu frazy mnemonicznej, w której każde słowo w frazie przypomina kolejne znaki w haśle. Na przykład fraza „dziewczyna idzie w dół deszczowej ulicy” mogłaby być przetłumaczona na d6!WdR5 lub, mniej prosto, d&6!RrlW@WdR,57. To podejście może ułatwić zapamiętanie hasła, ale pamiętaj, że różne litery mają bardzo różne prawdopodobieństwa występowania na początku słów.
Zobacz: (Częstotliwość liter w języku Polskim).
Inną skuteczną techniką może być zapisywanie losowo generowanych haseł i przechowywanie ich w bezpiecznym miejscu, na przykład w portfelu, torebce lub sejfie na dokumenty. Większość ludzi dobrze chroni swoje fizyczne kosztowności przed kradzieżą, a większości ludzi łatwiej jest zrozumieć najlepsze praktyki bezpieczeństwa fizycznego w porównaniu z praktykami bezpieczeństwa cyfrowego.
Bardzo skuteczne jest również łączenie techniki mnemonicznej i losowej poprzez zapisywanie długich, losowo generowanych haseł w menedżerze haseł, do którego dostęp uzyskuje się za pomocą łatwego do zapamiętania "hasła głównego" / "hasła pierwotnego", które musi być używane tylko w tym celu. Hasło główne musi być zapamiętane i nigdy nie zapisane. Wymaga to też zainstalowania menedżera haseł w systemie, aby łatwo uzyskać dostęp do haseł (co może być postrzegane jako niedogodność lub funkcja bezpieczeństwa, w zależności od sytuacji). Niektóre menedżery haseł posiadają również aplikacje mobilne, które mogą wyświetlać hasła do ręcznego wprowadzania na systemach, w których menedżer nie jest zainstalowany (jeśli jest to częsty przypadek użycia, zamiast całkowicie losowych haseł, możesz używać dla każdej usługi haseł bezpiecznych, ale łatwiejszych do wpisania – patrz poniżej). Pamiętaj, że menedżer haseł wprowadza pojedynczy punkt awarii, jeśli kiedykolwiek zapomnisz hasła głównego. Niektóre menedżery haseł obliczają zawarte hasła na podstawie hasła głównego i nazwy usługi, do której chcesz się zalogować, zamiast je szyfrować, co umożliwia korzystanie z nich w nowym systemie bez synchronizowania jakichkolwiek danych.
Skuteczne może być użycie łatwej do zapamiętania długiej serii niepowiązanych słów jako hasła. Teoria mówi, że jeśli użyta zostanie wystarczająco długa fraza, zdobyta entropia z długości hasła może przeciwdziałać utraconej entropii z użycia słów słownikowych. Ten komiks xkcd pokazuje kompromis entropii tej metody, biorąc pod uwagę ograniczony zestaw możliwych słów dla każdego słowa w haśle frazie. Jeśli zestaw słów, które wybierasz, jest duży (wiele tysięcy słów) i wybierasz z niego 5-7 lub nawet więcej losowych słów, ta metoda zapewnia wielką entropię, nawet zakładając, że atakujący zna zestaw możliwych słów wybranych i liczbę wybranych słów. Liczba możliwych haseł fraz po ustaleniu zestawu słów i ich liczby wynosi: (liczba słów w zestawie do wyboru) do potęgi (liczby słów wybranych dla hasła frazy).
Zobacz: Diceware. The passphrase FAQ lub Mocne hasło aby zgłębić temat.
Zarządzanie hasłami
Po wybraniu silnego hasła należy je bezpiecznie przechowywać. Uważaj na keyloggery (oprogramowanie i sprzęt), programy rejestrujące zawartość ekranu, inżynierię społeczną, podglądanie przez ramię. Nie używaj tego samego hasła w różnych miejscach, gdyż w sytuacji wycieku danych z jednego serwisu narażasz wszystkie swoje konta. Menedżer haseł może pomóc w zarządzaniu dużą liczbą złożonych haseł: jeśli kopiujesz i wklejasz zapisane hasła z menedżera do aplikacji, które ich potrzebują, pamiętaj, aby za każdym razem czyścić schowek i upewnić się, że nie są one zapisywane w żadnym dzienniku (np. nie wklejaj ich w zwykłych poleceniach terminala, które przechowują je w plikach takich jak .bash_history). Należy pamiętać, że menedżery haseł zaimplementowane jako rozszerzenia przeglądarki mogą być podatne na ataki kanału bocznego. Można to ograniczyć, korzystając z menedżerów haseł działających jako oddzielne aplikacje.
Z zasady nie należy wybierać niebezpiecznych haseł tylko dlatego, że bezpieczne są trudniejsze do zapamiętania. Hasła to kwestia kompromisu. Lepiej jest mieć zaszyfrowaną bazę danych bezpiecznych haseł, chronioną kluczem i jednym silnym hasłem głównym, niż wiele podobnych, słabych haseł. Zapisywanie haseł (np. na kartce) jest prawdopodobnie równie skuteczne [1], ponieważ pozwala uniknąć potencjalnych luk w zabezpieczeniach oprogramowania, wymagając jednocześnie zabezpieczenia fizycznego.
Jeśli używasz tego samego hasła do szyfrowania dysku, co hasła logowania (przydatne np. do automatycznego montowania zaszyfrowanej partycji lub folderu podczas logowania), upewnij się, że /etc/shadow znajduje się na zaszyfrowanej partycji i/lub używa silnej funkcji generowania klucza (tj. yescrypt / argon2 lub sha512 z PBKDF2, ale nie md5 lub niskich iteracji w PBKDF2) dla przechowywanego skrótu hasła (więcej informacji można znaleźć w SHA password hashes).
passwd, aby zastosować nowe domyślne ustawienia.Jeśli tworzysz kopię zapasową bazy danych haseł, upewnij się, że żadna kopia nie jest przechowywana za pomocą innego hasła, które z kolei jest w niej przechowywane, np. na zaszyfrowanym dysku lub w uwierzytelnionej usłudze zdalnego przechowywania danych, ponieważ w razie potrzeby nie będziesz w stanie uzyskać do niej dostępu. Przydatną sztuczką jest zabezpieczenie dysków lub kont, na których znajduje się kopia zapasowa bazy danych, za pomocą prostego skrótu kryptograficznego hasła głównego. Prowadź listę wszystkich lokalizacji kopii zapasowych: jeśli pewnego dnia będziesz podejrzewać, że hasło główne zostało naruszone, będziesz musiał natychmiast zmienić je we wszystkich kopiach zapasowych bazy danych i lokalizacjach chronionych kluczami pochodnymi od hasła głównego.
Bezpieczne kontrolowanie wersji bazy danych może być bardzo skomplikowane: jeśli zdecydujesz się to zrobić, musisz mieć możliwość aktualizacji hasła głównego wszystkich wersji bazy danych. Nie zawsze od razu wiadomo, kiedy hasło główne zostało ujawnione: aby zmniejszyć ryzyko, że ktoś inny odkryje Twoje hasło, zanim zorientujesz się, że zostało ujawnione, możesz zdecydować się na jego okresową zmianę. Jeśli obawiasz się, że utraciłeś kontrolę nad kopią bazy danych, musisz zmienić wszystkie hasła w niej zawarte w czasie, jaki może zająć złamanie hasła głównego metodą brute-force, w zależności od jego entropii.
Menedżery haseł
Najprawdopodobniej, najlepszym rozwiązaniem będzie dla ciebie, będzie wykorzystanie jakiegoś menedżera haseł, ponieważ jest to program który, będzie za Ciebie przetrzymywał i generował nowe hasła, dobrze skonfigurowany pomaga też bronić się przed Phishingiem. Jednak sam powinieneś wybrać najlepszą metodę dla ciebie,
QT_QPA_PLATFORM=xcb, lub rozpocząć KeePassXC z flagą keepassxc -platform xcb.Programy do zarządzania hasłami możemy podzielić ze względu:
Wadą takich rozwiązań jest, że od teraz jeśli ktoś posiada hasło główna posiada dostęp do twoich WSZYSTKICH haseł (zawartych w bazie), musisz zabezpieczyć hasło do bazy z hasłami. Jeżeli zdecydowałeś się na opcje działającą lokalnie, ponosisz PEŁNĄ odpowiedzialność za utrzymanie spójności danych, synchronizację między urządzeniami oraz tworzenie kopii zapasowych zaszyfrowanej bazy danych. Rozwiązanie chmurowe, wiąże się z podwyższonym prawdopodobieństwem utraty kontroli operacyjnej nad fizycznym położeniem i infrastrukturą bazy haseł. (w skrócie, najpewniej kiedyś ta baza wycieknie.)
Można niektóre z tych problemów ograniczyć, poprzez wykorzystanie metody Haseł podwójnie ślepych/ Horcruxing, zakłada ona, że ani ty, ani wybrany przez Ciebie menedżer haseł nie zna pełnego hasła, tylko posiadacie po kawałku hasła, dzięki czemu utrudnisz atakującemu wykorzystanie twojej bazy z hasłami, gdyż musi jakoś uzyskać Twoją część haseł.
Zobacz: Hasła podwójnie ślepe Dokumentacja KeePassXC
Zobacz: WebAuthn, Konfiguracja U2F dla konta użytkownika
Hasze haseł
Hash (funkcja skrótu) jest funkcją jednokierunkową, co oznacza, że została zaprojektowana tak, aby niemożliwe było wywnioskowanie danych wejściowych na podstawie jej wyniku bez ponownego obliczenia funkcji haszującej z tymi danymi. (Przykłady: MD5, SHA.)
Funkcja haszowania hasła została zaprojektowana tak, aby uniemożliwić odgadnięcie danych wprowadzonych przez użytkownika (hasła) bez obliczenia funkcji haszującej (przykład: bcrypt). Funkcja wyprowadzania klucza (KDF; przykłady: yescrypt, scrypt, PBKDF2) to algorytm kryptograficzny zaprojektowany w celu wyprowadzenia tajnych kluczy (np. klucza AES, skrótu hasła) z danych wejściowych (klucza głównego, hasła). W związku z tym funkcja KDF może służyć wielu zastosowaniom, w tym funkcji skrótu hasła.
Domyślnie Arch przechowuje zhaszowane hasła użytkowników w pliku /etc/shadow, który jest dostępny tylko dla administratora root, oddzielnie od innych parametrów użytkowników przechowywanych w pliku /etc/passwd, który jest dostępny dla wszystkich użytkowników, patrz Users and groups#User database. Zobacz także #Restricting root[broken link: invalid section].
Hasła są ustawiane za pomocą polecenia „passwd”, które rozciąga je za pomocą funkcji kryptograficznej systemu, a następnie zapisuje w /etc/shadow. Hasła są również solone, aby chronić je przed atakami tęczowych tablic. Zobacz: How are passwords stored in Linux (Understanding hashing with shadow utils), lub z nowszego Understanding /etc/shadow file format on Linux.
Ponieważ skróty haseł mają określony format, metodę i parametr można skonfigurować dla kolejnych nowych wywołań polecenia passwd. W związku z tym poszczególne skróty przechowywane w pliku /etc/shadow mogą stanowić heterogeniczną mieszankę funkcji skrótu obsługiwanych przez system.
Więcej informacji na temat formatu, metod haszowania i parametrów można znaleźć w crypt(5).
Plik /etc/login.defs konfiguruje domyślną metodę haszowania haseł, przez ENCRYPT_METHOD YESCRYPT oraz jej parametr YESCRYPT_COST_FACTOR.
Na przykład zwiększenie domyślnego parametru YESCRYPT_COST_FACTOR spowoduje logarytmiczny wzrost czasu obliczeniowego wymaganego do wyprowadzenia skrótu z hasła. Dotyczy to również osób trzecich próbujących uzyskać tajne hasło oraz systemu uwierzytelniającego logowanie użytkownika.
Natomiast czas obliczeniowy funkcji skrótu SHA-512 jest konfigurowany za pomocą parametru o liniowym wpływie. Informacje na temat poprzedniego domyślnego ustawienia Arch można znaleźć w sekcji Skróty haseł SHA. Należy pamiętać, że algorytm yescrypt wykorzystuje wewnętrznie funkcje SHA-256, HMAC i PBKDF2 do obliczania skrótu hasła. Głównym powodem jest połączenie pozytywnych cech tych szeroko stosowanych i przetestowanych funkcji w celu zwiększenia odporności na ataki. Na przykład użyteczność SHA do różnych celów spowodowała wsparcie sprzętowe dla tej funkcji, tj. wydajność obliczania czystego skrótu SHA znacznie wzrosła, co sprawia, że jego zastosowanie jako funkcji skrótu hasła staje się coraz bardziej przestarzałe.
Wymuszanie silnych haseł za pomocą pam_pwquality
pam_pwquality zapewnia ochronę przed Atakami słownikowymi i pomaga skonfigurować zasady dotyczące haseł, które mogą być egzekwowane w całym systemie. Jest oparty na pam_cracklib, więc jest wstecznie kompatybilny z jego opcjami.
Zainstaluj pakiet libpwquality.
- Możesz użyć konta root, żeby ustawić hasło dla użytkownika, które omija żądaną/skonfigurowaną politykę. Jest to przydatne przy ustawianiu tymczasowych haseł.
Jeśli na przykład chcesz egzekwować tę politykę:
- dwukrotne zapytanie o hasło w przypadku błędu (opcja retry)
- minimalna długość 10 znaków (opcja minlen)
- co najmniej 6 znaków powinno różnić się od starego hasła podczas wprowadzania nowego (opcja difok)
- co najmniej 1 cyfra (opcja dcredit)
- co najmniej 1 wielka litera (opcja ucredit)
- co najmniej 1 mała litera (opcja lcredit)
- co najmniej 1 inny znak (opcja ocredit)
- nie może zawierać słów „myservice” i „mydomain”
- egzekwuj zasady dla użytkownika root
Edytuj plik /etc/pam.d/passwd, aby wyglądał następująco:
#%PAM-1.0 password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root password required pam_unix.so use_authtok sha512 shadow
Polecenie password required pam_unix.so use_authtok nakazuje modułowi pam_unix nie wyświetlać zapytania o podanie hasła, lecz użyć hasła dostarczonego przez moduł pam_pwquality.
Więcej informacji można znaleźć na stronach podręcznika pam_pwquality(8) i pam_unix(8).
CPU
Microkod
Informacje na temat instalowania ważnych aktualizacji zabezpieczeń mikrokodu procesora można znaleźć w sekcji microcode.
Luki w zabezpieczeniach sprzętu
Niektóre procesory zawierają luki w zabezpieczeniach sprzętu. Lista tych luk oraz przewodniki dotyczące wyboru środków zaradczych, które pomogą dostosować jądro w celu złagodzenia tych luk w konkretnych scenariuszach użytkowania, znajdują się w dokumentacji jądra dotyczącej luk w zabezpieczeniach sprzętu.
Aby sprawdzić, czy dotyczy Cię znana luka w zabezpieczeniach, uruchom następujące polecenie:
$ grep -r . /sys/devices/system/cpu/vulnerabilities/
W większości przypadków aktualizacja jądra i mikrokodu pozwoli złagodzić luki bezpieczeństwa.
Wielowątkowość współbieżna (hyper-threading)
Wielowątkowość współbieżna (SMT), zwane również hiperwątkowością w procesorach Intel, to funkcja sprzętowa, która może być źródłem luk w zabezpieczeniach L1 Terminal Fault i Microarchitectural Data Sampling. Aktualizacje jądra systemu Linux i mikrokodu zawierają środki zaradcze dla znanych luk w zabezpieczeniach, ale W przypadku niektórych procesorów może być nadal konieczne wyłączenie funkcji SMT, jeśli obecne są niezaufane goście wirtualizacji.
Funkcję SMT można często wyłączyć w oprogramowaniu układowym systemu. Więcej informacji można znaleźć w dokumentacji płyty głównej lub systemu. Funkcję SMT można również wyłączyć w jądrze, dodając następujący parametr jądra:
mitigations=auto,nosmt
Pamięć
Wzmocnienie malloc
hardened_mallocAUR jest wzmocnionym zamiennikiem funkcji malloc() biblioteki glibc. Projekt został pierwotnie opracowany przez Daniela Micaya z GrapheneOS w celu integracji z Biometrią i musl systemu Android, ale autor dodał również obsługę standardowych dystrybucji systemu Linux w architekturze x86_64.
Chociaż hardened_malloc nie jest jeszcze zintegrowany z glibc (mile widziana pomoc i prośby o pull), można go łatwo używać z LD_PRELOAD. W dotychczasowych testach powoduje on problemy tylko w kilku aplikacjach, jeśli jest włączony globalnie w /etc/ld.so.preload. Ponieważ hardened_malloc ma wpływ na wydajność, warto zdecydować, której implementacji użyć w poszczególnych przypadkach, w oparciu o aktualne rodzaje ataku i wymagania dotyczące wydajności.
Aby wypróbować to w trybie samodzielnym, użyj skryptu opakowującego hardened-malloc-preload lub ręcznie uruchom aplikację z odpowiednią wartością preload:
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox
Właściwe użycie Firejail można znaleźć na jego stronie wiki, a niektóre konfigurowalne opcje kompilacji dla hardened_malloc można znaleźć w repozytorium github.
Pamięć masowa
Szyfrowanie danych w spoczynku
Szyfrowanie danych w spoczynku, przy czym preferowane jest szyfrowanie całego dysku za pomocą silnego hasła frazy, jest to jedyny sposób ochrony danych przed fizycznym odzyskaniem. Zapewnia to poufność danych, gdy komputer jest wyłączony lub dyski są odmontowane.
Jednak po włączeniu komputera i zamontowaniu dysku dane na nim przechowywane stają się tak samo podatne na zagrożenia jak w przypadku dysku niezaszyfrowanego. Dlatego najlepszym rozwiązaniem jest odmontowanie partycji danych, gdy tylko przestaną być potrzebne.
Można również zaszyfrować dysk za pomocą klucza przechowywanego w module TPM, chociaż w przeszłości występowały luki w zabezpieczeniach i klucz można uzyskać za pomocą ataku typu TPM-sniffing.
Niektóre programy, takie jak dm-crypt, umożliwiają użytkownikowi szyfrowanie pliku pętli jako wirtualnego woluminu. Jest to rozsądna alternatywa dla szyfrowania całego dysku, gdy tylko niektóre części systemu wymagają zabezpieczenia.
Chociaż typy szyfrowania oparte na urządzeniach blokowych lub systemach plików porównane w artykule data-at-rest encryption są przydatne w ochronie danych na nośnikach fizycznych, większość z nich nie może być używana do ochrony danych w systemie zdalnym, nad którym nie masz kontroli (takim jak pamięć masowa w chmurze). W niektórych przypadkach przydatne będzie szyfrowanie poszczególnych plików.
Oto kilka metod szyfrowania plików:
- Niektóre narzędzia do archiwizacji i kompresji zapewniają również podstawowe szyfrowanie. Przykładami są 7-Zip (flaga
-p), zip (flaga-e). Szyfrowanie powinno być stosowane wyłącznie z zachowaniem szczególnej ostrożności, ponieważ narzędzia te mogą wykorzystywać niestandardowe algorytmy w celu zapewnienia kompatybilności między platformami. [3] - GnuPG może być używane do szyfrowania plików.
- age to proste i łatwe w użyciu narzędzie do szyfrowania plików. Obsługuje również wielu odbiorców i szyfrowanie przy użyciu kluczy SSH, co jest przydatne do bezpiecznego udostępniania plików.
Systemy plików
Jądro zapobiega teraz problemom bezpieczeństwa związanym z dowiązaniami fizycznymi i symbolicznymi, jeśli przełączniki sysctl fs.protected_hardlinks i fs.protected_symlinks są włączone, więc oddzielanie katalogów z prawem zapisu dla wszystkich użytkowników nie zapewnia już znaczącej korzyści w zakresie bezpieczeństwa.
Systemy plików zawierające katalogi z prawem zapisu dla wszystkich użytkowników mogą być nadal przechowywane oddzielnie, co stanowi prosty sposób ograniczenia szkód wynikających z wyczerpania miejsca na dysku. Jednak zapełnienie katalogów /var lub /tmp wystarczy, aby unieruchomić usługi. Istnieją bardziej elastyczne mechanizmy radzenia sobie z tym problemem (takie jak limity), a niektóre systemy plików same zawierają podobne funkcje (Btrfs ma limity na podwoluminach).
Opcje montażu
Zgodnie z zasadą minimalnych uprawnień systemy plików powinny być montowane przy użyciu najbardziej restrykcyjnych opcji montowania (bez utraty funkcjonalności).
Odpowiednie opcje montażu to:
-
nodev: Nie interpretuj znaków lub bloków urządzeń specjalnych w systemie plików. -
nosuid: Nie zezwalaj na działanie bitów set-user-identifier lub set-group-identifier. -
noexec: Nie zezwalaj na bezpośrednie wykonywanie żadnych plików binarnych w zamontowanym systemie plików.- Ustawienie
noexecw/homeuniemożliwia wykonywanie skryptów i działania programów Wine, Steam, PyCharm, .NET itp.- Wine nie potrzebuje flagi
execdo otwierania plików binarnych systemu Windows. Jest ona potrzebna tylko wtedy, gdy Wine jest zainstalowane w katalogu/home. - Aby Steam działał poprawnie, można zamontować
/home/user/.local/share/Steamjakoexecw fstab, dodając następujący wpis:/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0
- Wine nie potrzebuje flagi
- Niektóre pakiety (na przykład nvidia-dkms[broken link: replaced by nvidia-open-dkms]) mogą wymagać
execw/var.
- Ustawienie
Systemy plików używane do przechowywania danych powinny być zawsze montowane z opcjami nodev, nosuid i noexec.
Potencjalne montowania systemu plików do rozważenia:
/var/home/dev/shm/tmp/boot
{{Tip (Polski)|W przypadku korzystania z automatycznego montowania partycji GPT, partycje ESP i XBOOTLDR są zawsze zabezpieczane za pomocą noexec,nosuid,nodev.
Migawki
Korzystając z migawek systemu plików, np. w Btrfs, LVM lub ZFS, należy pamiętać, że migawki mogą zawierać poufne informacje, które użytkownicy oczekują, że zostaną usunięte. Dotyczy to zwłaszcza sytuacji, gdy skonfigurowane są narzędzia do automatycznego tworzenia migawek, takie jak Snapper, ponieważ mogą one przechwytywać migawki w regularnych odstępach czasu lub w odpowiedzi na zdarzenia systemowe. Oto kilka przykładów tego, jak poufne informacje w /home/ mogą pozostać w migawkach:
-
Usunięte pliki i katalogi: Nawet jeśli pliki lub katalogi zostały usunięte z systemu plików, mogą nadal istnieć w starszych migawkach. W większości przypadków jest to normalne, ale warto rozważyć, czy pliki i katalogi takie jak
.local/share/Trash/,.historyitp. powinny zostać zachowane. -
Pliki tymczasowe i pamięć podręczna: Pliki tymczasowe i dane z pamięci podręcznej generowane przez aplikacje mogą być zawarte w migawkach. Na przykład pliki przechowywane w zaszyfrowanych katalogach mogą generować miniatury (
.cache/thumbnails) lub kopie robocze po otwarciu, które z kolei mogą być zawarte w migawkach. To samo dotyczy np. historii przeglądania (.mozilla/,.config/chromium/itp.), która mogła zostać uwzględniona w migawce przed jej usunięciem.
Jeśli jest to obsługiwane, rozważ całkowite wykluczenie takich katalogów z migawek. Na przykład, jeśli używasz Btrfs, możesz utworzyć podwoluminy, takie jak .cache/, .config/, .local/, .var/ lub dowolny inny katalog zgodnie z Twoim przypadkiem użycia.
.local/share/Trash do oddzielnego podwoluminu może w niektórych przypadkach spowodować nieprawidłowe działanie funkcji kosza, np. w przypadku GNOME/Files.Uprawnienia dostępu do plików
Domyślne uprawnienia do plików pozwalają na dostęp do prawie wszystkiego, a zmiana uprawnień może ukryć cenne informacje przed atakującym, który uzyska dostęp do konta niebędącego kontem root, takiego jak użytkownicy http lub nobody. Możesz użyć chmod, aby odebrać wszystkie uprawnienia grupie i innym osobom:
# chmod go-r część_do_ukrycia
g z polecenia (lub ponowne dodanie uprawnień za pomocą chmod g+r część, jeśli polecenie zostało już uruchomione).Niektóre ścieżki, które warto rozważyć, to:
-
/boot: Katalog boot, który może zawierać tradycyjne obrazy vmlinuz i initramfs lub Jednolity obraz jądra. Należy pamiętać, że podczas korzystania z systemd#GPT partition automounting domyślnie stosowane są bezpieczne uprawnienia. -
/etc/nftables.conf: Konfiguracja nftables, mająca zastosowanie do nftables i iptables-nft. -
/etc/iptables: Starsza konfiguracja iptables, mająca zastosowanie do iptables.
Domyślną wartość umask 0022 można zmienić, aby poprawić bezpieczeństwo nowo tworzonych plików. W Przewodniku bezpieczeństwa NSA RHEL5 sugeruje się ustawienie umask na 0077 w celu zapewnienia maksymalnego bezpieczeństwa, co sprawia, że nowe pliki nie są czytelne dla użytkowników innych niż właściciel. Aby to zmienić, zobacz Umask#Set the mask value. Jeśli używasz sudo, rozważ skonfigurowanie go tak, aby używał domyślnej maski root.
Pliki SUID i SGID
Ważne jest, aby mieć świadomość istnienia plików z bitem Setuid lub Setgid. Przykłady plików z ustawionym bitem SUID:
- unix_chkpwd
- chage, expiry, gpasswd, groupmems, passwd, sg (shadow)
- fusermount3, fusermount2
- pkexec, polkit-agent-helper-1[4] (polkit)
- ssh-keysign
- chfn, chsh, mount, newgrp, umount, wall, write (util-linux)
- sudo, sudo-rs, doas, su, su-rs, ksu
- firejail
- dbus-daemon-launch-helper
- chromium-sandbox
- Xorg.wrap
Do głównych zagrożeń związanych z takimi plikami wykonywalnymi należą luki w zabezpieczeniach umożliwiające podwyższenie uprawnień, patrz np. Wikipedia:Setuid#Security impact.[5][6][7]
Pliki z ustawionym bitem SUID, które nie należą do użytkownika root, lub pliki z ustawionym bitem SGID zazwyczaj mają mniejszy potencjalny wpływ, ale teoretycznie nadal mogą wyrządzić spore szkody, jeśli są podatne na ataki. Zazwyczaj można uniknąć używania SUID lub SGID, przypisując zamiast tego Capabilities.
Aby wyszukać pliki z bitem SUID lub SGID:
$ find / -perm "/u=s,g=s" -type f 2>/dev/null
Kopie zapasowe
Regularnie twórz kopie zapasowe ważnych danych. Regularnie sprawdzaj integralność kopii zapasowych. Regularnie sprawdzaj, czy kopie zapasowe można przywrócić.
Upewnij się, że co najmniej jedna kopia danych jest przechowywana w trybie offline, tj. nie jest w żaden sposób połączona z systemem, który jest zagrożony. Oprogramowanie ransomware i inne destrukcyjne ataki mogą również zaatakować wszelkie podłączone systemy kopii zapasowych.
Można skorzystać z zasady 3-2-1 czyli, z zasady mówiącej, że minimalne rozwiązanie do tworzenia kopii zapasowych powinno zawierać trzy kopie danych, w tym dwie kopie lokalne i jedną kopię poza twoim domem, na wypadek np. pożaru. Najprościej wykonać kopie zapasowe za pomocą programu takiego jak deja-dup, oczywiście zaleca się je zaszyfrować. Co może wydać się oczywiste, ale zaznaczę to tutaj, reguła powinna tyczyć się baz z hasłami, jeżeli zdecydowałeś się na użycie keepassxc, lub każdego innego który nie działa w chmurze, ponieważ w przypadku utraty takiej bazy tracisz dostęp do swoich haseł.
Tryb zamrożenia dysku SSD SATA
Zobacz: Solid state drive#Setting the SATA SSD state to frozen mode after waking up from sleep.
Konfiguracja użytkownika
Nie korzystaj z konta root do codziennego użytku
Zgodnie z zasadą najmniejszego przywileju, nie należy używać konta root do codziennego użytkowania. Dla każdej osoby korzystającej z systemu należy utworzyć konto użytkownika bez uprawnień. Sposoby tymczasowego uzyskania uprawnień specjalnych opisano w sekcji List of applications (Polski)/Security (Polski)#Podniesienie uprawnień.
Wprowadź opóźnienie po nieudanej próbie logowania
Dodaj następujący wiersz do pliku /etc/pam.d/system-login, aby dodać co najmniej 4-sekundowe opóźnienie między nieudanymi próbami logowania:
/etc/pam.d/system-login
auth optional pam_faildelay.so delay=4000000
4000000 jest czasem opóźnienia w mikrosekundach.
pam_faildelay mogą również sugerować takie opóźnienie; jeśli zrobi to wiele modułów, PAM użyje najdłuższego z nich.
W szczególności zarówno pam_unix, jak i pam_faillock domyślnie ustawiają minimalne opóźnienie wynoszące 2 sekundy.
Aby całkowicie usunąć to opóźnienie, należy dodać parametr nodelay do wszystkich linii auth tych modułów, np.
/etc/pam.d/system-auth
auth [success=1 default=bad] pam_unix.so try_first_pass nullok nodelay
Zablokuj użytkownika po trzech nieudanych próbach logowania
Od wersji pambase 20200721.1-2, pam_faillock.so jest domyślnie włączone, aby blokować użytkowników na 10 minut po 3 nieudanych próbach logowania w ciągu 15 minut (patrz FS#67644). Blokada dotyczy tylko uwierzytelniania hasłem (np. logowanie i „sudo”), uwierzytelnianie kluczem publicznym przez SSH jest nadal akceptowane. Aby zapobiec całkowitemu odmowie usługi, blokada ta jest domyślnie wyłączona dla użytkownika root.
Aby odblokować użytkownika, wykonaj następujące czynności:
$ faillock --user username --reset
Domyślnie mechanizm blokujący to plik dla każdego użytkownika, który znajduje się w /run/faillock/. Usunięcie lub opróżnienie pliku odblokowuje tego użytkownika — katalog należy do roota, ale plik należy do użytkownika, więc polecenie faillock tylko opróżnia plik, więc nie wymaga uprawnień roota.
Moduł pam_faillock.so można skonfigurować za pomocą pliku /etc/security/faillock.conf. Parametry blokady:
-
unlock_time— czas blokady (w sekundach, domyślnie 10 minut). -
fail_interval— czas, w którym nieudane logowania mogą spowodować blokadę (w sekundach, domyślnie 15 minut). -
deny— liczba nieudanych logowań przed blokadą (domyślnie 3).
deny = 0 całkowicie wyłączy mechanizm blokady.Domyślnie wszystkie blokady użytkowników są tracone po ponownym uruchomieniu systemu. Jeśli osoba atakująca może ponownie uruchomić komputer, bezpieczniej jest, aby blokady pozostały aktywne. Aby blokady pozostały aktywne, należy zmienić parametr dir w /etc/security/faillock.conf na /var/lib/faillock.
Aby zmiany zaczęły obowiązywać, nie trzeba restartować systemu. Więcej opcji konfiguracyjnych, takich jak włączenie blokady konta root, wyłączenie scentralizowanego logowania (np. LDAP) itp., znajdziesz w faillock.conf(5).
Ogranicz liczbę procesów
W systemach z dużą liczbą użytkowników lub użytkownikami, którym nie ufamy, ważne jest, aby ograniczyć liczbę procesów, które każdy z nich może uruchomić jednocześnie, zapobiegając w ten sposób fork bombom i innym atakom typu denial-of-service. Konfiguracja /etc/security/limits.conf określa, ile procesów może mieć otwartych każdy użytkownik lub grupa, i domyślnie jest pusta (z wyjątkiem przydatnych komentarzy). Dodanie poniższych wierszy do tego pliku ograniczy wszystkich użytkowników do 100 aktywnych procesów, chyba że użyją oni polecenia prlimit, aby wyraźnie podnieść maksymalną liczbę do 200 dla tej sesji. Wartości te można zmienić zgodnie z odpowiednią liczbą procesów, które użytkownik powinien uruchamiać, lub sprzętem komputera, którym zarządzasz.
* soft nproc 100 * hard nproc 200
Aktualną liczbę wątków dla każdego użytkownika można sprawdzić za pomocą polecenia ps --no-headers -Leo user | sort | uniq --count. Może to pomóc w określeniu odpowiednich wartości limitów dla użytkowników; zobacz także limits.conf.
Używaj Wayland
Preferuj używanie Wayland zamiast Xorg. Projekt Xorg powstał przed wprowadzeniem nowoczesnych praktyk bezpieczeństwa i przez wielu jest uważany za niebezpieczny. Na przykład klienci Xorg mogą rejestrować naciśnięcia klawiszy, gdy są nieaktywne.
Jeśli musisz uruchomić Xorg, zaleca się uniknięcie uruchamiania go jako root. W Waylandzie warstwa kompatybilności Xwayland automatycznie użyje rootless Xorg.
Ogranicz konto root
Użytkownik root jest z definicji najpotężniejszym użytkownikiem w systemie. Trudno jest również przeprowadzić audyt konta użytkownika root. Dlatego ważne jest, aby w jak największym stopniu ograniczyć korzystanie z konta użytkownika root. Istnieje wiele sposobów na zachowanie uprawnień użytkownika root przy jednoczesnym ograniczeniu jego możliwości wyrządzenia szkody.
Używaj sudo zamiast su
Parę powodów, żeby korzystać z sudo zamiast su do podnoszenia uprawnień.
- Prowadzi dziennik, w którym zapisuje, który użytkownik z normalnymi uprawnieniami uruchomił każde z poleceń wymagających uprawnień administratora.
- Nie ma potrzeby podawania hasła administratora każdemu użytkownikowi, który potrzebuje dostępu do uprawnień administratora.
-
sudozapobiega przypadkowemu uruchamianiu przez użytkowników poleceń jako „root”, które nie wymagają uprawnień administratora, ponieważ nie jest tworzony pełny terminal administratora. Jest to zgodne z zasadą najmniejszego przywileju. - Poszczególne programy mogą być włączane dla poszczególnych użytkowników, zamiast oferować pełny dostęp root tylko w celu uruchomienia jednego polecenia. Na przykład, aby dać użytkownikowi archie dostęp do określonego programu:
# visudo
/etc/sudoers
archie ALL = NOPASSWD: /path/to/program
Można też zezwolić na używanie poszczególnych poleceń wszystkim użytkownikom. Aby zamontować udziały Samba z serwera jako zwykły użytkownik:
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs
Dzięki temu wszyscy użytkownicy należący do grupy users mogą uruchamiać polecenia /sbin/mount.cifs i /sbin/umount.cifs z dowolnego komputera (ALL).
nano zamiast vi z visudo,
/etc/sudoers
Defaults editor=/usr/bin/rnano
Eksportowanie EDITOR=nano visudo jest uważane za poważne zagrożenie bezpieczeństwa, ponieważ wszystko może być używane jako EDITOR.
Edytowanie plików za pomocą sudo
Zobacz Sudo#Editing files. Alternatywnie można użyć edytora takiego jak rvim lub rnano, który ma ograniczone możliwości, aby można było go bezpiecznie uruchamiać jako root.
Ograniczanie logowania jako root
Po prawidłowym skonfigurowaniu sudo pełny dostęp administratora może zostać znacznie ograniczony lub zablokowany bez utraty użyteczności. Aby wyłączyć administratora, ale nadal umożliwić korzystanie z sudo, można użyć passwd(1) z passwd --lock root.
Zezwól tylko zaufanym użytkownikom
Plik PAM pam_wheel.so pozwala tylko użytkownikom z grupy wheel logować się za pomocą su. Zobacz su#su and wheel.
Zablokuj logowanie przez SSH
Nawet jeśli nie chcesz blokować logowania root dla lokalnych użytkowników, zawsze warto zablokować logowanie root przez SSH. Ma to na celu dodanie dodatkowej warstwy zabezpieczeń, zanim użytkownik będzie mógł całkowicie przejąć kontrolę nad systemem zdalnie.
Określanie akceptowalnych kombinacji logowania za pomocą access.conf
-:ALL:ALL. [8]
Kiedy ktoś próbuje się zalogować za pomocą PAM, sprawdzany jest plik /etc/security/access.conf pod kątem pierwszej kombinacji, która pasuje do jego właściwości logowania. Jego próba kończy się niepowodzeniem lub sukcesem w zależności od reguły dla tej kombinacji.
+:root:LOCAL -:root:ALL
Reguły można ustawić dla określonych grup i użytkowników. W tym przykładzie użytkownik archie może logować się lokalnie, podobnie jak wszyscy użytkownicy z grup wheel i adm. Wszystkie inne logowania są odrzucane:
+:archie:LOCAL +:(wheel):LOCAL +:(adm):LOCAL -:ALL:ALL
Przeczytaj więcej na access.conf(5)
Obowiązkowa kontrola dostępu (MAC)
Mandatory access control (MAC) to rodzaj polityki bezpieczeństwa, która znacznie różni się od dyskrecjonalnej kontroli dostępu (DAC) stosowanej domyślnie w Archu i większości dystrybucji Linuksa. MAC zasadniczo oznacza, że każda czynność wykonywana przez program, która w jakikolwiek sposób wpływa na system, jest sprawdzana pod kątem zestawu reguł bezpieczeństwa. W przeciwieństwie do metod DAC, zestaw ten nie może być modyfikowany przez użytkowników. Zastosowanie praktycznie dowolnego systemu obowiązkowej kontroli dostępu znacznie poprawi bezpieczeństwo komputera, chociaż istnieją różnice w sposobie jego wdrażania.
Ścieżka dostępu MAC
Kontrola dostępu oparta na ścieżkach to prosta forma kontroli dostępu, która przyznaje uprawnienia na podstawie ścieżki danego pliku. Wadą tego rodzaju kontroli dostępu jest to, że uprawnienia nie są przenoszone wraz z plikami, jeśli są one przenoszone w obrębie systemu. Zaletą jest natomiast to, że kontrola dostępu oparta na ścieżkach może być wdrażana w znacznie szerszym zakresie systemów plików, w przeciwieństwie do alternatywnych rozwiązań opartych na etykietach.
- AppArmor to implementacja MAC utrzymywana przez Canonical, postrzegana jako „łatwiejsza” alternatywa dla SELinux.
- TOMOYO to kolejny prosty, łatwy w użyciu system oferujący obowiązkową kontrolę dostępu. Został zaprojektowany tak, aby był prosty zarówno w użyciu, jak i we wdrażaniu, wymagając bardzo niewielu zależności.
Etykiety MAC
Kontrola dostępu oparta na etykietach oznacza, że rozszerzone atrybuty pliku są wykorzystywane do zarządzania jego uprawnieniami bezpieczeństwa. Chociaż system ten jest prawdopodobnie bardziej elastyczny pod względem oferowanych zabezpieczeń niż kontrola dostępu oparta na ścieżkach, działa on tylko w systemach plików obsługujących te rozszerzone atrybuty.
- SELinux, oparty na projekcie NSA mającym na celu poprawę bezpieczeństwa systemu Linux, implementuje MAC całkowicie niezależnie od użytkowników systemu i ról. Oferuje niezwykle solidną, wielopoziomową implementację polityki MAC, która pozwala z łatwością utrzymać kontrolę nad systemem, który rozrasta się i zmienia w stosunku do swojej pierwotnej konfiguracji.
Listy kontroli dostępu
Listy kontroli dostępu (ACL) stanowią alternatywę dla bezpośredniego dołączania reguł do systemu plików. Listy ACL realizują kontrolę dostępu poprzez sprawdzanie działań programu względem listy dozwolonych zachowań.
Utwardzenie jądra
Samozabezpieczenie jądra / ograniczanie skutków exploitów
Pakiet linux-hardened wykorzystuje podstawowy zestaw poprawek wzmacniających zabezpieczenia jądra oraz opcje konfiguracyjne kompilacji bardziej ukierunkowane na bezpieczeństwo niż pakiet linux. Możliwe jest stworzenie niestandardowej kompilacji, aby wybrać inny kompromis między bezpieczeństwem a wydajnością niż domyślne ustawienia ukierunkowane na bezpieczeństwo.
Należy jednak pamiętać, że niektóre pakiety nie będą działać przy użyciu tego jądra. Na przykład throttled.
Jeśli korzystasz ze sterownika spoza drzewa, takiego jak NVIDIA, może być konieczne przełączenie się na jego pakiet DKMS.
Porównanie ASLR w przestrzeni użytkownika
Pakiet linux-hardened zapewnia ulepszoną implementację losowego rozmieszczenia przestrzeni adresowej dla procesów przestrzeni użytkownika. Polecenie paxtest może być użyte do uzyskania oszacowania dostarczonej entropii:
Procesy 64-bitowe
linux-hardened 5.4.21.a-1-hardened
Test randomizacji mapowania anonimowego : 32 bity jakości (oszacowane) Test randomizacji sterty (ET_EXEC) : 40 bitów jakości (oszacowane) Test randomizacji sterty (PIE) : 40 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (ET_EXEC) : 32 bity jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (PIE) : 32 bity jakości (oszacowane) Test randomizacji bibliotek współdzielonych : 32 bity jakości (oszacowane) Test randomizacji VDSO : 32 bity jakości (oszacowane) Test randomizacji stosu (SEGMEXEC) : 40 bitów jakości (oszacowane) Test randomizacji stosu (PAGEEXEC) : 40 bitów jakości (oszacowane) Test randomizacji argumentów/środowiska (SEGMEXEC) : 44 bity jakości (oszacowane) Test randomizacji argumentów/środowiska (PAGEEXEC) : 44 bity jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_EXEC): 34 bity jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_DYN) : 34 bity jakości (oszacowane) Randomizacja przy wyczerpaniu pamięci @~0: 32 bity (oszacowane) Randomizacja przy wyczerpaniu pamięci @0 : 32 bity (oszacowane)
linux 5.5.5-arch1-1
Test randomizacji mapowania anonimowego : 28 bitów jakości (oszacowane) Test randomizacji sterty (ET_EXEC) : 28 bitów jakości (oszacowane) Test randomizacji sterty (PIE) : 28 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (ET_EXEC) : 28 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (PIE) : 28 bitów jakości (oszacowane) Test randomizacji bibliotek współdzielonych : 28 bitów jakości (oszacowane) Test randomizacji VDSO : 20 bitów jakości (oszacowane) Test randomizacji stosu (SEGMEXEC) : 30 bitów jakości (oszacowane) Test randomizacji stosu (PAGEEXEC) : 30 bitów jakości (oszacowane) Test randomizacji argumentów/środowiska (SEGMEXEC) : 22 bity jakości (oszacowane) Test randomizacji argumentów/środowiska (PAGEEXEC) : 22 bity jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_EXEC): 28 bitów jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_DYN) : 28 bitów jakości (oszacowane) Randomizacja przy wyczerpaniu pamięci @~0: 29 bitów (oszacowane) Randomizacja przy wyczerpaniu pamięci @0 : 29 bitów (oszacowane)
linux-lts 4.19.101-1-lts
Test randomizacji mapowania anonimowego : 28 bitów jakości (oszacowane) Test randomizacji sterty (ET_EXEC) : 28 bitów jakości (oszacowane) Test randomizacji sterty (PIE) : 28 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (ET_EXEC) : 28 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (PIE) : 28 bitów jakości (oszacowane) Test randomizacji bibliotek współdzielonych : 28 bitów jakości (oszacowane) Test randomizacji VDSO : 19 bitów jakości (oszacowane) Test randomizacji stosu (SEGMEXEC) : 30 bitów jakości (oszacowane) Test randomizacji stosu (PAGEEXEC) : 30 bitów jakości (oszacowane) Test randomizacji argumentów/środowiska (SEGMEXEC) : 22 bity jakości (oszacowane) Test randomizacji argumentów/środowiska (PAGEEXEC) : 22 bity jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_EXEC): 28 bitów jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_DYN) : 28 bitów jakości (oszacowane) Randomizacja przy wyczerpaniu pamięci @~0: 28 bitów (oszacowane) Randomizacja przy wyczerpaniu pamięci @0 : 28 bitów (oszacowane)
Procesy 32-bitowe (na jądrze x86_64)
linux-hardened
Test randomizacji mapowania anonimowego : 16 bitów jakości (oszacowane) Test randomizacji sterty (ET_EXEC) : 22 bity jakości (oszacowane) Test randomizacji sterty (PIE) : 27 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (ET_EXEC) : Brak randomizacji Randomizacja głównego pliku wykonywalnego (PIE) : 18 bitów jakości (oszacowane) Test randomizacji bibliotek współdzielonych : 16 bitów jakości (oszacowane) Test randomizacji VDSO : 16 bitów jakości (oszacowane) Test randomizacji stosu (SEGMEXEC) : 24 bity jakości (oszacowane) Test randomizacji stosu (PAGEEXEC) : 24 bity jakości (oszacowane) Test randomizacji argumentów/środowiska (SEGMEXEC) : 28 bitów jakości (oszacowane) Test randomizacji argumentów/środowiska (PAGEEXEC) : 28 bitów jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_EXEC): 18 bitów jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_DYN) : 16 bitów jakości (oszacowane) Randomizacja przy wyczerpaniu pamięci @~0: 18 bitów (oszacowane) Randomizacja przy wyczerpaniu pamięci @0 : 18 bitów (oszacowane)
linux
Test randomizacji mapowania anonimowego : 8 bitów jakości (oszacowane) Test randomizacji sterty (ET_EXEC) : 13 bitów jakości (oszacowane) Test randomizacji sterty (PIE) : 13 bitów jakości (oszacowane) Randomizacja głównego pliku wykonywalnego (ET_EXEC) : Brak randomizacji Randomizacja głównego pliku wykonywalnego (PIE) : 8 bitów jakości (oszacowane) Test randomizacji bibliotek współdzielonych : 8 bitów jakości (oszacowane) Test randomizacji VDSO : 8 bitów jakości (oszacowane) Test randomizacji stosu (SEGMEXEC) : 19 bitów jakości (oszacowane) Test randomizacji stosu (PAGEEXEC) : 19 bitów jakości (oszacowane) Test randomizacji argumentów/środowiska (SEGMEXEC) : 11 bitów jakości (oszacowane) Test randomizacji argumentów/środowiska (PAGEEXEC) : 11 bitów jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_EXEC): 8 bitów jakości (oszacowane) Przesunięcie randomizacji bibliotek (ET_DYN) : 13 bitów jakości (oszacowane) Randomizacja przy wyczerpaniu pamięci @~0: Brak randomizacji Randomizacja przy wyczerpaniu pamięci @0 : Brak randomizacji
Ograniczanie dostępu do wskaźników jądra w systemie plików proc
Ustawienie kernel.kptr_restrict na 1 spowoduje ukrycie adresów symboli jądra w pliku /proc/kallsyms przed zwykłymi użytkownikami bez nieposiadającymi uprawnienia CAP_SYSLOG, utrudniając exploitom jądra dynamiczne rozwiązywanie adresów/symboli. Nie pomoże to zbytnio w przypadku prekompilowanego jądra Arch Linux, ponieważ zdeterminowany atakujący może po prostu pobrać pakiet jądra i ręcznie uzyskać symbole stamtąd, ale jeśli kompilujesz własne jądro, może to pomóc w ograniczeniu lokalnych exploitów root. Spowoduje to, że niektóre polecenia perf przestaną działać podczas używania ich przez użytkowników niebędących rootami (ale wiele funkcji perf i tak wymaga dostępu root). Więcej informacji można znaleźć w FS#34323.
Ustawienie kernel.kptr_restrict na 2 spowoduje ukrycie adresów symboli jądra w /proc/kallsyms niezależnie od uprawnień.
/etc/sysctl.d/51-kptr-restrict.conf
kernel.kptr_restrict = 1
Wzmocnienie BPF
BPF to system służący do dynamicznego ładowania i wykonywania kodu bajtowego w jądrze podczas działania systemu. Jest on wykorzystywany w wielu podsystemach jądra Linux, takich jak sieci (np. XDP, tc), śledzenie (np. kprobes, uprobes, tracepoints) i bezpieczeństwo (np. seccomp). Jest również przydatny do zaawansowanego bezpieczeństwa sieci, profilowania wydajności i dynamicznego śledzenia.
BPF było pierwotnie skrótem od Berkeley Packet Filter, ponieważ oryginalny klasyczny BPF był używany w narzędziach do przechwytywania pakietów dla BSD. Ostatecznie przekształciło się to w Extended BPF (eBPF), które wkrótce potem zostało przemianowane na BPF (nie jest to skrót). BPF nie należy mylić z narzędziami do filtrowania pakietów, takimi jak iptables lub netfilter, chociaż BPF może być używany do implementacji narzędzi do filtrowania pakietów.
Kod BPF może być interpretowany lub kompilowany przy użyciu kompilatora Just-In-Time (JIT). Jądro Arch jest zbudowane z CONFIG_BPF_JIT_ALWAYS_ON, co wyłącza interpreter BPF i wymusza użycie kompilacji JIT dla wszystkich BPF. Utrudnia to atakującym wykorzystanie BPF do eskalacji ataków wykorzystujących luki typu SPECTRE. Zobacz poprawkę jądra, która wprowadziła CONFIG_BPF_JIT_ALWAYS_ON.
Jądro zawiera funkcję wzmacniającą dla kompilowanego przez JIT BPF, która może złagodzić niektóre rodzaje ataków typu JIT spraying kosztem wydajności oraz możliwości śledzenia i debugowania wielu programów BPF. Można ją włączyć, ustawiając net.core.bpf_jit_harden na 1 (aby włączyć wzmocnienie kodu nieuprawnionego) lub 2 (aby włączyć wzmocnienie całego kodu).
Więcej szczegółów można znaleźć w ustawieniach net.core.bpf_* w dokumentacji jądra.
-
linux-hardened domyślnie ustawia
net.core.bpf_jit_harden=2zamiast0. - Domyślnie programy BPF mogą być uruchamiane nawet przez użytkowników bez uprawnień. Aby zmienić to zachowanie, ustaw
kernel.unprivileged_bpf_disabled=1[9].
Zakres ptrace
Wywołanie systemowe ptrace(2) zapewnia środek, dzięki któremu jeden proces („tracer”) może obserwować i kontrolować wykonywanie innego procesu („tracee”) oraz badać i zmieniać pamięć i rejestry tracee. ptrace jest powszechnie używane przez narzędzia do debugowania, w tym »'gdb«', »'strace«', »'perf«', »'reptyr«' i inne debuggery. Jednakże zapewnia ono również środek, za pomocą którego złośliwy proces może odczytywać dane z innych procesów i przejmować nad nimi kontrolę.
Arch domyślnie włącza Yama LSM, który zapewnia parametr jądra kernel.yama.ptrace_scope. Ten parametr jest domyślnie ustawiony na 1 (ograniczony), co uniemożliwia śledzącym wykonywanie wywołania ptrace na śladach poza ograniczonym zakresem, chyba że śledzący ma uprawnienia lub posiada CAP_SYS_PTRACE możliwości. Jest to znacząca poprawa bezpieczeństwa w porównaniu z klasycznymi uprawnieniami. Bez tego modułu nie ma rozdzielenia między procesami uruchomionymi jako ten sam użytkownik (przy braku dodatkowych warstw bezpieczeństwa, takich jak pid_namespaces(7)).
ptrace, uruchamiając je jako procesy uprzywilejowane, np. za pomocą sudo.Jeśli nie ma potrzeby korzystania z narzędzi do debugowania, warto rozważyć ustawienie kernel.yama.ptrace_scope na 2 (tylko dla administratorów) lub 3 (brak możliwości ptrace), aby wzmocnić zabezpieczenia systemu.
hidepid
Jądro ma możliwość ukrywania procesów innych użytkowników, normalnie dostępnych poprzez /proc, przed użytkownikami bez uprawnień poprzez zamontowanie systemu plików proc z opcjami hidepid= i gid= opisanymi w https://docs.kernel.org/filesystems/proc.html.
To znacznie utrudnia intruzowi zbieranie informacji o uruchomionych procesach, np. czy jakiś demon działa z podwyższonymi uprawnieniami, czy inny użytkownik uruchamia jakiś wrażliwy program, czy inni użytkownicy w ogóle uruchamiają jakieś programy, uniemożliwia sprawdzenie, czy któryś z użytkowników uruchamia konkretny program (zakładając, że program nie ujawnia się poprzez swoje zachowanie), a dodatkowo, źle napisane programy przekazujące wrażliwe informacje poprzez argumenty programu są teraz chronione przed lokalnymi podsłuchiwaczami.
The proc group, provided by the filesystem package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to /proc/<pid> directories beyond their own, add them to the group.
proc Grupa, udostępniana przez pakiet filesystem, pełni funkcję białej listy użytkowników uprawnionych do uzyskiwania informacji o procesach innych użytkowników. Jeśli użytkownicy lub usługi potrzebują dostępu do katalogów /proc/<pid> innych niż własne, należy dodać je do grupy.
Na przykład, aby ukryć informacje o procesie przed innymi użytkownikami z wyjątkiem tych z grupy proc:
/etc/fstab
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
Aby sesje użytkowników działały poprawnie, należy dodać wyjątek dla systemd-logind:
/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service] SupplementaryGroups=proc
Ograniczanie ładowania modułów
Domyślnie jądro Arch ma włączoną opcję CONFIG_MODULE_SIG_ALL, która podpisuje wszystkie moduły jądra skompilowane jako część pakietu linux. Dzięki temu jądro może ładować tylko moduły podpisane prawidłowym kluczem, co oznacza, że moduły spoza drzewa kompilowane lokalnie lub dostarczane przez pakiety takie jak virtualbox-host-modules-arch nie mogą być ładowane. Możesz użyć modinfo, aby sprawdzić, czy aktualnie załadowane moduły mają podpisy; ręczne sprawdzanie podpisów jest nieco bardziej skomplikowane (zobacz ten przegląd).
Ładowanie modułów jądra można ograniczyć, ustawiając parametr jądra module.sig_enforce=1. Więcej informacji można znaleźć w dokumentacji jądra.
Ponadto niepotrzebne moduły można umieścić na czarnej liście, przykłady można znaleźć na stronie secureblue
Wyłącz kexec
Kexec umożliwia zastąpienie aktualnie działającego jądra.
/etc/sysctl.d/51-kexec-restrict.conf
kernel.kexec_load_disabled = 1
Tryb blokady jądra
Od wersji Linux 5.4 jądro zyskało opcjonalną dreamwidth.org/55105.html funkcje lockdownu, mającą na celu wzmocnienie granicy między UID 0 (root) a jądrem. Po włączeniu tej funkcji niektóre aplikacje, które wymagają niskopoziomowego dostępu do sprzętu lub jądra, mogą przestać działać.
Aby użyć blokady, należy zainicjować jej LSM i ustawić tryb blokady.
Wszystkie oficjalnie obsługiwane jądra inicjują LSM, ale żadne z nich nie wymusza trybu blokady.
cat /sys/kernel/security/lsm.Blokada ma dwa tryby działania:
-
integrity: funkcje jądra, które umożliwiają użytkownikom modyfikowanie działającego jądra, są wyłączone (np. kexec, bpf). -
confidentiality: funkcje jądra, które umożliwiają użytkownikom uzyskanie poufnych informacji z jądra, są również wyłączone.
Zaleca się stosowanie integrity, chyba że konkretny model zagrożeń wymaga inaczej.
Aby włączyć blokadę jądra w czasie wykonywania, uruchom:
# echo mode > /sys/kernel/security/lockdown
Aby włączyć blokadę jądra podczas uruchamiania, użyj opcji parametru jądra lockdown=mode.
- Blokady jądra nie można wyłączyć w trakcie działania systemu.
- Blokada jądra wyłącza hibernacje.
Zobacz kernel_lockdown(7).
Linux Kernel Runtime Guard (LKRG)
LKRG (lkrg-dkmsAUR) jest modułem jądra, który sprawdza integralność jądra i wykrywa próby wykorzystania luk w zabezpieczeniach.
Wyłącz powłokę awaryjną
Powłoka awaryjna służy do interaktywnego rozwiązywania problemów z komputerem podczas procesu uruchamiania. Jest to jednak również narzędzie, które osoba atakująca może wykorzystać do uzyskania dostępu do zasobów zabezpieczonych, takich jak moduł TPM. Praktyczny przykład można znaleźć w tym artykule. Trudność ataków można zwiększyć, wyłączając powłokę awaryjną, co wiąże się jednak z rezygnacją z narzędzia do rozwiązywania problemów związanych z wczesnymi awariami podczas uruchamiania.
Aby wyłączyć powłokę awaryjną, zobacz systemd#Disable emergency mode on remote machine.
Aplikacje w Piaskownicy
Zobacz Wikipedia:pl:Piaskownica (bezpieczeństwo informatyczne).
Aby poprawić bezpieczeństwo jednostek usług systemd, zobacz systemd/Sandboxing.
CONFIG_USER_NS jest obecnie włączony w linux, linux-lts, linux-zen i linux-hardened. Jego brak może uniemożliwić udostępnienie aplikacjom niektórych funkcji piaskownicy.CONFIG_USER_NS_UNPRIVILEGED) jest domyślnie włączone w linux, linux-lts i linux-zen, co znacznie zwiększa powierzchnię ataku dla lokalnego podwyższenia uprawnień (zobacz AppArmor's Wiki i FS#36969).Aby złagodzić ten problem, należy:
- Użyj jądra linux-hardened, które ma bezpieczne ustawienia domyślne, lub
- Ustaw
kernel.unprivileged_userns_clonesysctl na0.
Należy pamiętać, że może to spowodować nieprawidłowe działanie aplikacji takich jak nsjail. Aplikacje oparte na Chromium wymagają bitu SUID, aby chrome-sandbox działało z tym ustawieniem.
Firejail
Firejail to łatwe w użyciu narzędzie do tworzenia piaskownic dla aplikacji i serwerów. Pierwotnie zostało stworzone dla przeglądarek i aplikacji internetowych, ale obecnie obsługuje wiele różnych aplikacji. Aby stworzyć środowisko piaskownicy z różnorodnymi funkcjami, jest instalowane jako plik binarny suid i tworzy środowisko uruchomieniowe piaskownicy dla docelowej aplikacji w oparciu o czarne i białe listy.
bubblewrap
bubblewrap to aplikacja typu sandbox opracowana dla narzędzi kontenerowych bez uprawnień, takich jak Flatpak, charakteryzująca się znacznie mniejszym zużyciem zasobów i mniejszą złożonością niż Firejail. Chociaż brakuje jej niektórych funkcji, takich jak biała lista ścieżek plików, bubblewrap oferuje montowanie bindów, a także tworzenie przestrzeni nazw użytkowników/IPC/PID/sieci/cgroup i może obsługiwać zarówno proste, jak i złożone piaskownice. W przypadku jądra linux-hardened należy użyć bubblewrap-suid.
Piaskownica Bubblejail jest oparty na bubblewrap i zapewnia model uprawnień zorientowany na zasoby z graficznym interfejsem do dostosowywania uprawnień.
Portable
Portable jest frameworkiem typu sandbox, który wykorzystuje bubblewrap i wiele innych narzędzi do blokowania uruchomionych aplikacji. Został zaprojektowany tak, aby był prosty dla pakujących i wydajny dla użytkowników, a jednocześnie domyślnie eliminuje luki w zabezpieczeniach i monitoruje procesy działające w tle.
Zobacz portable-arch, aby zapoznać się z repozytorium aplikacji izolowanych przez portable.
Jeśli aplikacja w piaskownicy nie korzysta z selektora plików portalu, portable może przekazać pliki do piaskownicy (przekazując --actions share-files).
Portable działa w pełni na GNOME, podczas gdy inne środowiska graficzne mogą nie posiadać niektórych funkcji, takich jak zaawansowane monitorowanie w tle i portal ScreenShot.
chroots
Ręczne środowiska chroot mogą być również tworzone w celu budowania środowisk procesów typu sandbox. Są one znacznie bardziej ograniczone niż inne technologie sandboxingu; zakres ich działania ogranicza się do izolacji ścieżek plików.
Kontenery Linux
Kontenery Linux są kolejną dobrą opcją, gdy potrzebujesz większej separacji niż zapewniają inne opcje (z wyjątkiem pełnej wirtualizacji systemu[broken link: invalid section]). LXC działa na istniejącym jądrze w pseudo-chroot z własnym sprzętem wirtualnym.
Pełne opcje wirtualizacji
Korzystanie z opcji pełnej wirtualizacji, takich jak VirtualBox, KVM, Xen lub Qubes OS (oparte na Xen), może również poprawić izolację i bezpieczeństwo w przypadku planowania uruchamiania ryzykownych aplikacji lub przeglądania niebezpiecznych stron internetowych.
Sieć i zapory sieciowe
Zapory sieciowe
Chociaż standardowe jądro Arch jest w stanie korzystać z Netfilter's iptables i nftables, usługi te nie są domyślnie włączone. Zaleca się skonfigurowanie jakiejś formy zapory sieciowej w celu ochrony usług działających w systemie. Wiele zasobów (w tym ArchWiki) nie określa wyraźnie, które usługi warto chronić, więc włączenie zapory sieciowej jest dobrym środkiem ostrożności.
- Ogólne informacje można znaleźć w sekcjach iptables i nftables.
- Instrukcje dotyczące konfiguracji zapory iptables można znaleźć w sekcji Simple stateful firewall
- Inne sposoby konfiguracji netfilter można znaleźć w sekcji Category:Firewalls.
- Informacje na temat list blokujących adresy IP, takich jak te z Bluetack, można znaleźć w sekcji Ipset.
- opensnitch to konfigurowalna zapora sieciowa dla ruchu przychodzącego i wychodzącego, obsługująca konfigurowalne reguły według aplikacji, portu, hosta itp.
Otwarte port
Niektóre usługi nasłuchują ruchu przychodzącego na otwartych portach sieciowych. Ważne jest, aby usługi te były powiązane wyłącznie z adresami i interfejsami, które są absolutnie niezbędne. Zdalny atakujący może wykorzystać wadliwe protokoły sieciowe, aby uzyskać dostęp do odsłoniętych usług. Może się to zdarzyć nawet w przypadku procesów powiązanych z lokalnym hostem.
Ogólnie rzecz biorąc, jeśli usługa musi być dostępna tylko dla systemu lokalnego, należy ją powiązać z gniazdem domeny Unix (unix(7)) lub adresem pętli zwrotnej, takim jak localhost, zamiast z adresem niebędącym adresem pętli zwrotnej, takim jak 0.0.0.0/0.
Jeśli usługa musi być dostępna dla innych systemów za pośrednictwem sieci, należy kontrolować dostęp za pomocą ścisłych reguł firewall i skonfigurować uwierzytelnianie, autoryzację i szyfrowanie, gdy tylko jest to możliwe.
Możesz wyświetlić listę wszystkich aktualnie otwartych portów za pomocą polecenia ss -l. Aby wyświetlić wszystkie procesy nasłuchujące oraz ich numeryczne numery portów tcp i udp:
# ss -lpntu
Zobacz ss(8) dla większej ilości opcji.
Parametry jądra
Parametry jądra, które mają wpływ na działanie sieci, można ustawić za pomocą Sysctl. Aby dowiedzieć się, jak to zrobić, zobacz Sysctl#TCP/IP stack hardening.
SSH
Aby ograniczyć skutki ataków brute-force, zaleca się stosowanie uwierzytelniania opartego na kluczach. W przypadku OpenSSH więcej zaleceń można znaleźć w sekcji OpenSSH#Protection. Alternatywnie, Fail2ban lub Sshguard oferują mniejszą ochronę poprzez monitorowanie logów i dynamiczne dodawanie reguł do firewall, ale narażają na potencjalny atak typu denial of service, ponieważ atakujący może spoofować pakiety tak, jakby pochodziły od administratora po zidentyfikowaniu jego adresu. Spoofing IP ma linie obrony, takie jak filtrowanie ścieżki zwrotnej i wyłączenie przekierowań ICMP.
Możesz chcieć jeszcze bardziej utwardzić uwierzytelnianie używając uwierzytelniania dwuskładnikowego. Autoryzator Google zapewnia dwuetapową procedurę uwierzytelniania przy użyciu jednokrotnego hasła (OTP).
Zablokowanie logowania roota jest również dobrą praktyką, zarówno do śledzenia włamań i dodaje dodatkową warstwę bezpieczeństwa przed dostępem roota. Dla OpenSSH, zobacz OpenSSH#Deny.
Mozilla publikuje poradnik konfiguracji OpenSSH, który obejmuje bardziej szczegółowe logowanie audytu (w trybie verbose) oraz ograniczenie algorytmów szyfrowania do bezpiecznych opcji.
DNS
Domyślna konfiguracja rozdzielczości nazw domen (DNS) jest wysoce kompatybilna, ale ma słabe zabezpieczenia. Więcej informacji można znaleźć w prywatny i bezpieczny DNS.
Proxies
Proxy są powszechnie wykorzystywane jako dodatkowa warstwa pomiędzy aplikacjami a siecią, filtrując dane z niezaufanych źródeł. Powierzchnia ataku małego proxy z niższymi uprawnieniami jest znacznie mniejsza niż złożona aplikacja z uprawnieniami użytkownika końcowego.
Na przykład resolver DNS jest implementowany w glibc, który jest połączony z aplikacją (mogącą działać jako root), więc błąd w resolver DNS może prowadzić do zdalnego wykonania kodu. Można temu zapobiec poprzez zainstalowanie serwera buforowego DNS, takiego jak dnsmasq, który działa jako pośrednik. [13]
Zarządzanie certyfikatami TLS
Zobacz TLS#Trust management.
Fizyczna ochrona
Fizyczny dostęp do komputera to dostęp root z wystarczającą ilością czasu i zasobów. Jednak wysoki praktyczny poziom bezpieczeństwa można osiągnąć poprzez wprowadzenie wystarczających barier.
Atakujący może uzyskać pełną kontrolę nad twoim komputerem w następnym uruchomieniu, po prostu dołączając złośliwy IEEE 1394 (FireWire), Thunderbolt lub PCI Urządzenie ekspresowe, ponieważ domyślnie daje im pełny dostęp do pamięci. [14] Dla Thunderbolt, można ograniczyć bezpośredni dostęp pamięci całkowicie lub do znanych urządzeń, zobacz Thunderbolt#User device authorization. Dla FireWire i PCI Express niewiele można zrobić bez modyfikacji sprzętu, aby temu zapobiec. Jednak zdecydowana większość atakujących nie będzie tego świadoma i zdecydowana.
#Data-at-rest encryption[broken link: invalid section] uniemożliwi dostęp do twoich danych, jeśli komputer zostanie skradziony, ale złośliwy firmware może być zainstalowane w celu uzyskania tych danych przy następnym logowaniu przez zaradnego atakującym.
Utwardzenie BIOS'u
Dodanie hasła do BIOS uniemożliwia komuś uruchomienie komputera z pendrive, co w zasadzie jest takie, jak posiadanie dostępu do komputera. Należy upewnić się, że Twój dysk jest pierwszy w kolejności startowej i wyłączyć inne dyski z bootable, jeśli można.
Boot loaders
Bardzo ważne jest, aby chronić boot loader. Niezabezpieczony boot loader może obejść wszelkie ograniczenia logowania, np. poprzez ustawienie opcji init=/bin/sh parametr jądra, aby uruchomić bezpośrednio do powłoki.
Syslinux
Syslinux wspiera ustawienie hasła na boot loader. Pozwala ustawić albo hasło pozycji per- menu- lub globalne hasło loadera.
GRUB
GRUB również obsługuje hasła dla programu rozruchowego (boot loadera). Szczegóły znajdziesz w Ochrona hasłem GRUB menu. Posiada także obsługę zaszyfrowanego /boot, co pozostawia niezaszyfrowane jedynie niektóre części kodu programu rozruchowego. Konfiguracja GRUB-a, kernel i initramfs są zaszyfrowane.
systemd-boot
systemd-boot wyłącza edycję parametrów jądra (kernela), gdy włączona jest funkcja #Secure Boot. Alternatywnie, zobacz systemd-boot#Kernel parameters editor with password protection dla bardziej tradycyjnej opcji opartej na haśle.
Secure Boot
Secure Boot (Bezpieczny Rozruch) to funkcja UEFI, która umożliwia uwierzytelnienie plików, z których uruchamia się komputer. Pomaga to zapobiegać niektórym atakom "złej pokojówki", takim jak podmiana plików wewnątrz partycji rozruchowej. Zazwyczaj komputery są dostarczane z kluczami, które są zarejestrowane przez dostawców (OEM). Można je jednak usunąć, co pozwala komputerowi wejść w tryb konfiguracji (Setup Mode), umożliwiający użytkownikowi rejestrowanie i zarządzanie własnymi kluczami.
Strona Secure Boot przeprowadzi Cię przez proces konfiguracji bezpiecznego rozruchu poprzez użycie własnych kluczy.
Trusted Platform Module (TPM)
Moduły TPM to sprzętowe mikroprocesory, które mają wbudowane klucze kryptograficzne. Stanowi to fundamentalne źródło zaufania dla większości nowoczesnych komputerów i umożliwia kompleksową weryfikację łańcucha rozruchowego. Mogą być używane jako wewnętrzne karty inteligentne, poświadczać oprogramowanie układowe (firmware) działające na komputerze oraz umożliwiać użytkownikom przechowywanie poufnych danych w odpornym na manipulacje i ataki siłowe magazynie.
Partycja rozruchowa na wymiennym dysku flash
Jednym z popularnych pomysłów jest umieszczenie partycji rozruchowej na dysku flash, aby uniemożliwić uruchomienie systemu bez niego. Zwolennicy tego pomysłu często używają jednocześnie pełnego szyfrowania dysku[broken link: invalid section], a niektórzy również stosują odłączane nagłówki szyfrujące umieszczone na partycji rozruchowej.
Tę metodę można również połączyć z szyfrowaniem /boot.
Automatyczne wylogowywanie
Jeśli używasz Bash lub Zsh, możesz ustawić TMOUT, by automatycznie wylogowywał się z powłoki po ustalonym czasie.
Na przykład, poniższy kod spowoduje automatyczne wylogowanie z wirtualnych konsol (ale nie z emulatorów terminala w X11):
/etc/profile.d/shell-timeout.sh
TMOUT="$(( 60*10 ))"; [ -z "$DISPLAY" ] && export TMOUT; case $( /usr/bin/tty ) in /dev/tty[0-9]*) export TMOUT;; esac
Jeśli naprawdę chcesz, aby KAŻDY prompt Bash/Zsh (nawet wewnątrz X) miał limit czasu (timeout), użyj:
$ export TMOUT="$(( 60*10 ))";
Zauważ, że nie zadziała to, jeśli w powłoce (shellu) działa jakieś polecenie (np. sesja SSH lub inna powłoka bez obsługi TMOUT). Ale jeśli używasz VC (konsoli wirtualnej) głównie do restartowania zamrożonego GDM/Xorg jako root, to jest to bardzo przydatne.
Ochrona przed niebezpiecznymi urządzeniami USB
Jądro systemu (kernel) posiada ustawienia, które dezaktywują porty USB, aby chronić Twój komputer przed niebezpiecznymi urządzeniami USB (znanymi również jako BadUSB, PoisonTap lub LanTurtle). Można je ustawiać w czasie działania systemu i automatyzować za pomocą sysctl.
Aby uzyskać większą kontrolę, zainstaluj USBGuard, który jest frameworkiem programowym implementującym podstawowe możliwości białych (whitelisting) i czarnych list (blacklisting) w oparciu o atrybuty urządzenia.
Gromadzenie danych ulotnych (Volatile data collection)
Włączony komputer może być podatny na gromadzenie danych ulotnych. Dobrą praktyką jest całkowite wyłączanie komputera, gdy nie potrzebne jego działanie, lub gdy jego fizyczne bezpieczeństwo jest tymczasowo naruszone (np. podczas przechodzenia przez punkt kontroli).
Pakiety
Bezpieczeństwo AUR
AUR (Arch User Repository) zawiera pakiety tworzone i utrzymywane przez społeczność, nie są one weryfikowane przez deweloperów Arch Linux. Instalacja z AUR odbywa się na własne ryzyko.
Zalecane praktyki
- Sprawdź PKGBUILD i pliki .install, szukaj podejrzanych poleceń: `rm -rf`, `curl ... | sh`, `wget ... -O- | sh`.
- Zweryfikuj sumy kontrolne (`sha256sums`, `b2sums`) i adresy URL, muszą prowadzić do oficjalnych źródeł upstream.
- Mile widziane, jest zgłaszanie złośliwych pakietów, warto zostawić komentarz pod takim pakietem, gdyż mogą uchronić mniej doświadczonych użytkowników przed instalacją złośliwego pakietu.
Pomocnicy AUR
Narzędzia takie jak yayAUR, czy paruAUR ułatwiają instalację takich pakietów, ale nie są oficjalnie wspierane, mogą mieć luki, lub pomijać wyświetlenie skryptu instalacyjnego.
Zobacz: Pomocnicy AUR
Uwierzytelnienie
Ataki na menedżerów pakietów są możliwe bez właściwego stosowania podpisywania pakietów i mogą mieć wpływ nawet na menedżerów pakietów z sprawnymi systemami podpisu. Arch używa domyślnie podpisywania pakietów i opiera się na sieci zaufania z 5 zaufanych kluczy głównych. Szczegółowe informacje znajdują się w Pacman-key.
Aktualizacje
Niezbędnym jest regularne aktualizowanie systemu.
Obserwuj aktualne podatności
Subskrybowanie aktualizacji "Common Vulnerabilities and Exposure" (CVE) Security Alert, udostępnianych przez National Vulnerability Database i dostępnych na stronie pobierania NVD. Arch Linux Security Tracker służy jako szczególnie użyteczne źródło, ponieważ łączy zestawy danych Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) i CVE w formacie tabelarycznym. Narzędzie arch-audit może być używane do sprawdzania luk w zabezpieczeniach dotykających uruchomiony system. Można również użyć graficznej ikony na pasku systemowym, arch-audit-gtk. Zobacz także Arch Security Team.
Powinieneś również rozważyć subskrybowanie powiadomień o nowych wydaniach dla używanego oprogramowania, zwłaszcza jeśli instalujesz oprogramowanie za pomocą innych środków niż główne repozytoria lub AUR. Niektóre programy mają listy mailingowe, które możesz subskrybować, aby otrzymywać powiadomienia dotyczące bezpieczeństwa. Witryny hostujące kod źródłowy często oferują kanały RSS dla nowych wydań.
Przebudowa pakietów
Pakiety można ponownie budować, usuwając z nich niepożądane funkcje i cechy, co jest sposobem na zmniejszenie powierzchni ataku. Na przykład, pakiet bzip2 można przebudować bez bzip2recover, próbując obejść lukę CVE-2016-3189. Niestandardowe flagi utwardzające (hardening flags) można również zastosować ręcznie lub za pomocą specjalnego wrappera.
Ponowne budowanie pakietów (Rebuilding packages)
| Flag | Purpose |
|---|---|
| -D_FORTIFY_SOURCE=2 | Wykrywanie przepełnienia bufora w czasie działania programu (run-time) |
| -D_GLIBCXX_ASSERTIONS | Sprawdzanie granic w czasie działania (run-time bounds checking) dla ciągów i kontenerów C++ |
| -fasynchronous-unwind-tables | Zwiększona niezawodność śladów stosu (backtraces) |
| -fexceptions | Włącza anulowanie wątku w oparciu o tabele (table-based thread cancellation) |
| -fpie -Wl,-pie | Pełne ASLR dla plików wykonywalnych |
| -fpic -shared | Brak relokacji tekstu dla bibliotek współdzielonych |
| -fplugin=annobin | Generowanie danych dla kontroli jakości utwardzania (hardening quality control) |
| -fstack-clash-protection | Zwiększona niezawodność wykrywania przepełnienia stosu (stack overflow detection) |
| -fstack-protector, -fstack-protector-all or -fstack-protector-strong | Ochrona przed rozbiciem stosu (Stack smashing protector) |
| -grecord-gcc-switches | Przechowywanie flag kompilatora w informacjach debugowania |
| -mcet -fcf-protection | Ochrona integralności przepływu sterowania (Control flow integrity protection) |
| -Werror=format-security | Odrzucanie potencjalnie niebezpiecznych argumentów formatujących ciągi (format string arguments) |
| -Werror=implicit-function-declaration | Odrzucanie brakujących prototypów funkcji |
| -Wl,-z,defs | Wykrywanie i odrzucanie niepełnego łączenia (underlinking) |
| -Wl,-z,now | Wyłączanie leniwego wiązania (lazy binding) |
| -Wl,-z,relro | Segmenty tylko do odczytu po relokacji (Read-only segments after relocation) |