Security (Polski)

Status tłumaczenia:
Ten artykuł jest przetłumaczoną wersją
Security
. Data ostatniego tłumaczenia: 2025-12-15. Możesz pomóc zsynchronizować tłumaczenie, jeśli nastąpiły
zmiany
w wersji angielskiej.
Powiązane artykuły
Arch Security Team
General recommendations (Polski)
Identity management
Capabilities
List of applications (Polski)/Security (Polski)
Arch package guidelines/Security
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%
, lub
Qwedsazxc123
).
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
apg
AUR
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
).
Wskazówka
Arch Linux zmienił algorytm
domyślnego haszowania
na yescrypt. Jeśli nie dostosowałeś domyślnych ustawień, konieczne (i wystarczające) jest wykonanie zmiany hasła za pomocą
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,
Ostrzeżenie
Program
keepassxc
posiada wbudowaną w siebie opcje auto-wpisywania, ale sprawdza ona tytuł, a nie adres strony, przez co strony Phishingowe mogą dostać hasło od menedżera KeePassXC. Jest to spowodowane tym, że łatwiej można odczytać tytuł okna, niż zawartość paska adresowego. Jednakże KeePassXC oferuje inną metodę (rozszerzenie do przeglądarki), która bazuje na adresie URL.
Uwaga
Dodatkowo funkcja ta w Wayland jest domyślnie wyłączona należy ustawić
QT_QPA_PLATFORM=xcb
, lub rozpocząć KeePassXC z flagą
keepassxc -platform xcb
.
Programy do zarządzania hasłami możemy podzielić ze względu:
Tworzącą bazę lokalnie, przykład
keepassxc
Tworzącą bazę w chmurze, przykład
bitwarden
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
Wskazówka
Jeśli strona oferuje, wykorzystaj logowanie dwuskładnikowe. Zapewnia ona mniejsze prawdopodobieństwo nieautoryzowanego dostępu do twoich kont.
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
.
Ostrzeżenie
Konto
root
nie podlega domyślnie tej polityce.
Uwaga
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
Ostrzeżenie
To jest tylko przykład, nie zaleca się takiej polityki, ponieważ nie poprawia ona
bezpieczeństwa
(zobacz też
CERT.pl
). Obecne wytyczne odradzają wymuszanie znaków specjalnych, cyfr czy liter, bo prowadzą do przewidywalnych zmian i frustrują użytkowników. Zamiast tego skup się na długości hasła (minimum 15 znaków, jeśli jest jedynym sposobem uwierzytelniania).
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
.
Uwaga
Wyłączenie SMT jest korzystne głównie dla hiperwizorów.
[2]
W zwykłym systemie ma to bardzo małe lub żadne korzyści dla bezpieczeństwa.
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_malloc
AUR
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.
The factual accuracy of this article or section is disputed.
Reason:
Firefox może wymagać przebudowy, aby korzystanie z hardened-malloc było skuteczne. (Discuss in
Talk:Security (Polski)#Use of hardened-malloc with Firefox
)
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
noexec
w
/home
uniemożliwia wykonywanie skryptów i działania programów
Wine
,
Steam
, PyCharm,
.NET
itp.
Wine nie potrzebuje flagi
exec
do 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/Steam
jako
exec
w
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
Niektóre pakiety (na przykład
nvidia-dkms
[
broken link
: replaced by
nvidia-open-dkms
]
) mogą wymagać
exec
w
/var
.
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/
,
.history
itp. 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.
Uwaga
Przeniesienie
.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
The factual accuracy of this article or section is disputed.
Reason:
chmod go-r
nie „usuwa wszystkich uprawnień”, a jedynie uprawnienia do odczytu. (Discuss in
Talk:Security (Polski)
)
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
Ostrzeżenie
Nie stosuj tego rozwiązania na szeroką skalę. Wypróbuj je najpierw dla jednej konfiguracji, upewniając się, że warto ją ukryć i że nie zakłóci to działania programu. Jeśli grupa jest niezbędna, może być konieczne usunięcie
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
[
broken link
: replaced by
iptables
]
.
/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
.
Wskazówka
Aby zapobiec sytuacji, w której system jest podatny na ataki, należy być czujnym i dbać o aktualność pakietów zawierających pliki wykonywalne SUID/SGID.
Aby wyszukać pliki z bitem SUID lub SGID:
$ find / -perm "/u=s,g=s" -type f 2>/dev/null
Kopie zapasowe
This article or section is a candidate for merging with
System backup
.
Notes:
Istnieje specjalna strona poświęcona kopiom zapasowym systemu. (Discuss in
Talk:Security (Polski)
)
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.
Uwaga
Inne moduły PAM oprócz
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).
Wskazówka
Głównym celem blokady jest spowolnienie ataków brute-force, tak aby stały się one niewykonalne. Dlatego też, jeśli blokady spowodowane błędnym wpisaniem hasła stają się zbyt częste, lepszym rozwiązaniem może być zwiększenie liczby prób, niż skrócenie czasu blokady.
Uwaga
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
This article or section is a candidate for merging with
sudo
.
Notes:
Istnieje specjalny artykuł na ten temat. (Discuss in
Talk:Security (Polski)
)
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.
sudo
zapobiega 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).
Wskazówka
Aby używać ograniczonej wersji
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
Ostrzeżenie
Regresja w GNOME 49 powoduje zawieszanie się GDM, jeśli ustawisz regułę
-: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
Uwaga
linux-hardened
domyślnie ustawia
kptr_restrict=2
zamiast
0
.
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
.
Wskazówka
linux-hardened
domyślnie ustawia
net.core.bpf_jit_harden=2
zamiast
0
.
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)
).
Uwaga
Domyślnie nadal można używać narzędzi wymagających
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
This article or section needs expansion.
Reason:
Linux 5.8 wdrożył prywatne instancje
i nowe wartości dla
hidepid=
. (Discuss in
Talk:Security (Polski)
)
The factual accuracy of this article or section is disputed.
Reason:
Włączenie
hidepid
globalnie nie jest obsługiwanym sposobem działania przez
systemd
, ani nie zapewnia żadnych praktycznych korzyści pod względem bezpieczeństwa, gdy systemd działa jako menedżer usług.
[10]
(Discuss in
Talk:Security (Polski)
)
Ostrzeżenie
Może to powodować problemy w niektórych aplikacjach, takich jak aplikacje działające w piaskownicy i
Xorg
(zobacz rozwiązanie).
Powoduje to problemy z
D-Bus
,
Polkit
,
PulseAudio
i
bluetooth
podczas korzystania z
systemd
> 237.64-1.
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
Wskazówka
kexec domyślnie wyłączony jest w
linux-hardened
.
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.
Wskazówka
Zainicjowane moduły LSM można zweryfikować, uruchamiając
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
.
Uwaga
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-dkms
AUR
) jest modułem jądra, który sprawdza integralność jądra i wykrywa próby wykorzystania luk w zabezpieczeniach.
Wyłącz powłokę awaryjną
The factual accuracy of this article or section is disputed.
Reason:
Maskowanie
emergency.target
i
emergency.service
nie będzie miało wpływu na jednostki dodawane do initramfs i uruchamiane we wczesnej przestrzeni użytkownika. Nawet jeśli znajdują się one w initramfs, hak systemd mkinitcpio blokuje konto root.
[11]
[12]
ze względów bezpieczeństwa (patrz
FS#70408
). Rozwiązaniem problemu opisanego w artykule, o ile jest ono w ogóle potrzebne, byłoby zapobieganie dodawaniu
rescue.target
,
rescue.service
,
emergency.target
i
emergency.service
do obrazu initramfs. (Discuss in
Talk:Security (Polski)
)
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
.
Uwaga
Element konfiguracyjny przestrzeni nazw użytkownika
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.
Ostrzeżenie
Wykorzystanie przestrzeni nazw użytkownika bez uprawnień (
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_clone
sysctl
na
0
.
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
This article or section needs language, wiki syntax or style improvements. See
Help:Style
for reference.
Reason:
„Otwarte porty” nie jest dobrym tytułem, ponieważ pomija interfejsy i adresy, z którymi aplikacja może być powiązana. Z punktu widzenia zapór sieciowych porty mogą być „otwarte”, nawet jeśli żadna aplikacja nie nasłuchuje na nich w danym momencie. (Discuss in
Talk:Security (Polski)
)
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
.
Ostrzeżenie
W 2025 roku odnotowano przypadki złośliwych PKGBUILD-ów w AUR (np. CHAOS RAT, podawane jako patch do
przeglądarki
). Zawsze sprawdzaj kod przed instalacją.
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
yay
AUR
, czy
paru
AUR
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.
This article or section is a candidate for merging with
Arch package guidelines/Security
.
Notes:
Flagi kompilatora związane z bezpieczeństwem mają swój własny artykuł. (Discuss in
Talk:Security (Polski)
)
The factual accuracy of this article or section is disputed.
Reason:
kopiowano i wklejono z bloga sprzed 3 lat. Flagi kompilatora są specyficzne dla
GCC
, a niektóre z nich są ledwo związane z bezpieczeństwem. (Discuss in
Talk:Security (Polski)
)
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)
Flags and info source
Zobacz też
Arch Linux Security Tracker
CentOS Wiki: OS Protection
Hardening the Linux desktop
Hardening the Linux server
Linux Foundation: Linux workstation security checklist
privacyguides.org Privacy Resources
Red Hat Enterprise Linux 7 Security Guide
Securing Debian Manual
The paranoid #! Security Guide