A

gdybym Ci powiedział, że Linux nie potrzebuje żadnego zewnętrznego klienta DHCP, menedżera sieciowego ani innego narzędzia do konfiguracji sieci, aby skutecznie przeprowadzić proces konfiguracji jednego interfejsu sieciowego na dowolnym serwerze? Wystarczy tylko jądro i bootloader. W dodatku metoda ta jest kompatybilna wstecz aż do wersji Linuksa 2.0 z 1996 roku. Mowa tutaj o mechanizmie nfsroot, który pierwotnie został stworzony dla stacji bezdyskowych, a zawarty w nim parametr jądra ip= to przydatne narzędzie, które może w różnych sytuacjach pomóc skonfigurować sieć bez dodatkowego oprogramowania. Jeśli dobrze się wczytamy to dokumentacja nfsroot definiuje składnię parametru ip=, który poinstruuje jądro, jak skonfigurować wybrany interfejs sieciowy podczas startu systemu. Choć nazwa sugeruje powiązanie z NFS (ang. Network File System), mechanizm ten działa niezależnie od tego, czy ostatecznie zamontujemy system plików przez sieć. Jego składnia jest bardzo prosta:

ip=[klient]:[server]:[brama]:[maska]:[host]:[interfejs]:[autokonf]:[dns0]:[dns1]:[ntp0]

Gdzie:

• klient – to adres IP jaki chcemy przypisać interfejsowi sieciowemu.
• server – adres IP serwera NFS (możemy pominąć, jeśli nie montujemy systemu plików).
• brama – adres IP bramy sieciowej odpowiedzialnej za dostęp do sieci / internetu.
• maska – maska sieciowa definiująca do jakiej podsieci należy adres IP z pola klient.
• host – nazwa hosta / serwera.
• interfejs – nazwa interfejsu sieciowego, dla którego chcemy skonfigurować adresację sieciową.
• autokonf – określa jakim protokołem skonfigurować interfejs: dhcp, bootp, rarp lub off (statycznie).
• dns0 – adres pierwszego serwera DNS (działa tylko serwerem NFS), który pojawi się w /proc/net/pnp.
• dns1 – adresu drugiego serwera DNS (działa tylko serwerem NFS), który pojawi się w /proc/net/pnp.
• ntp0 – adres serwera NTP, który pojawi się w /proc/net/ipconfig/ntp_servers.

Przykłady:

GRUB_CMDLINE_LINUX="ip=192.168.254.2::192.168.254.1:255.255.255.0:darkstar:enp0s8:off:::"

Ustawi na interfejsie enp0s8 statyczny adres IP: 192.168.254.2/24, którego bramą sieciową jest: 192.168.254.1. Jeśli nie podamy nazwy interfejsu sieciowego zostanie wybrany pierwszy interfejs w systemie.

GRUB_CMDLINE_LINUX="ip=:::::enp0s8:dhcp:::"

Skonfiguruje interfejs enp0s8 za pomocą protokołu DHCP. Jeśli nie podamy nazwy interfejsu sieciowego zostanie wybrany pierwszy interfejs w systemie. Natomiast jeśli posiadamy tylko jeden interfejs to sprawa uproszcza się do krótkiego wpisu:

GRUB_CMDLINE_LINUX="ip=dhcp"

Fraza GRUB_CMDLINE_LINUX w powyższych przykładach pojawia się nie bez powodu, ponieważ zastosowanie tej metody w systemie (np. Debian / Ubuntu) wymaga zmodyfikowania parametrów startowych w programie rozruchowym GRUB. Poprzez edycję pliku: /etc/default/grub i dopisanie do linii GRUB_CMDLINE_LINUX odpowiednio dobranego parametru ip= aktywujemy mechanizm przy starcie systemu. Po edycji i zapisie w/w pliku wymagana jest aktualizacja konfiguracji GRUB:

sudo update-grub

Należy tylko pamiętać, że sterownik karty sieciowej musi być wkompilowany w jądro systemu lub dostępny w obrazie initrd/initramfs.

Więcej informacji: Setting a Static IP Address Using the Kernel Command Line, Kernel-only network configuration on Linux

W

wielu przypadkach zachodzi potrzeba wpisania wrażliwych danych / sekretów do poleceń w interaktywnej powłoce systemowej, np. bash. Często są to klucze API, tokeny lub hasła używane do sprawdzenia poprawności uwierzytelnienia, pobierania testowych danych itd. Niestety bezpośrednie wpisywanie tego typu danych do poleceń udostępnia je wszystkim osobom w współdzielonym systemie, które mogą widzieć Twoje procesy. Tego typu dane również lądują w plikach historii, które w przypadku udanej infekcji bardzo często są celem atakujących. W standardowej konfiguracji systemu Linux wiersze poleceń procesów są widoczne dla wszystkich użytkowników poprzez system plików /proc. W ten sposób działają takie narzędzia jak ps lub pgrep – przeszukują rekurencyjnie katalogi poszczególnych identyfikatorów procesów i odczytują pliki (np. cmdline, environ, status) opisujące każdy proces. Oczywiście możemy użyć specjalnej opcji montowania (hidepid) dla systemu plików proc, aby uniemożliwić innym użytkownikom inspekcję procesów. Jednak ten zabieg nadal powoduje „wyciek” danych do pliku historii, o którego czyszczeniu nie zawsze się pamięta.
[ czytaj całość… ]

S

Ocket CAT, czyli socat to uniwersalne narzędzie dla systemów *nix służące do dwukierunkowego transferu danych pomiędzy dwoma niezależnymi kanałami danych. Tymi kanałami mogą być: pliki, potoki, urządzenia, gniazda (SSL, Unix, IPv4, IPv6, surowe, UDP, TCP), proxy, deskryptory plików (standardowe wejścia, wyjścia itp.). Można go używać jako potężniejszy odpowiednik netcat, umożliwiający przekierowywanie portów, tworzenie i ograniczanie bezpiecznych połączeń, rozwiązywanie problemów sieciowych, czy realizację zaawansowanych scenariuszy przesyłania danych – działając jak „szwajcarski scyzoryk” do obsługi gniazd sieciowych i strumieni do komunikacji między procesami. Poniżej znajduje się kilka przykładów jego zastosowania:
[ czytaj całość… ]

Z

e względu na ograniczoną liczbę publicznych adresów IPv4, a także aby chronić systemy przez zagrożeniami z internetu wiele komputerów umieszczanych jest za zaporami sieciowymi. W wielu przypadkach funkcję zapory sieciowej pełni domowy / firmowy router, który również tłumaczy lokalny adres sieciowy komputera np. 192.168.0.10 na publiczny adres IP od ISP za pomocą mechanizmu translacji adresów sieciowych, czyli NAT (ang. Network Address Translation). W połączeniu ze stanowymi regułami zapory sieciowej teoretycznie oznacza to, że atakujący nie może bezpośrednio z internetu połączyć się z komputerem wewnątrz takiej sieci – pierwsze / inicjujące połączenie musi być nawiązane z wewnątrz chronionej sieci. W takiej konfiguracji, gdy dwa komputery są za różnymi zaporami stanowymi (ang. stateful firewall) z mechanizmem NAT i będą chciały skomunikować się ze sobą bezpośrednio – niezależnie od tego, który z nich rozpocznie połączenie, zapora sieciowa tego drugiego może odrzucić przychodzące pakiety danych.
[ czytaj całość… ]

K

orzystając z protokołu NTP (ang. Network Time Protocol) możemy mieć pewność, że nasze serwery synchronizują swój czas z wyspecjalizowanymi serwerami czasu opartymi na zegarach atomowych (w zależności od poziomu stratum). Utrzymanie precyzyjnego i aktualnego czasu na serwerach (i ogólnie urządzeniach biorących udział w komunikacji) nie jest tylko kwestią możliwości odpowiedzi na pytanie: „- która godzina?”. Poprawny czas na różnego rodzaju urządzeniach to krytyczny element stabilności, bezpieczeństwa i spójności danych. Jeśli zegar serwera znacząco odbiega od rzeczywistości to wiele usług używających czasu w swoich mechanizmach może zacząć działać niepoprawnie. Na przykład duże różnice w postaci dni, miesięcy i lat mogą powodować uznawanie certyfikatów SSL/TLS za nieważne (wydane w przeszłości lub przyszłości). Mniejsze różnice mieszczące się w oknie od 2 do 5 minut mogą powodować problemy z kodami uwierzytelniającymi dla OTP, 2FA, czy Kerberos – bo różnica czasu między klientem, a serwerem spowoduje ich odrzucenie.
[ czytaj całość… ]

O

podstawach działania narzędzia whois oraz jego dobrym działaniu jako źródle informacji pisałem nie raz. W aktualnej publikacji zajmiemy się zupełnie innym zastosowaniem tego narzędzia, a mianowicie eksfiltracją danych – znaną również jako wykradanie lub eksport danych do lokalizacji kontrolowanej przez atakującego. Słowem małego przypomnienia whois to prosty protokół żądania i odpowiedzi, powszechnie używany do przeszukiwania baz danych zawierających zarejestrowanych użytkowników obiektów internetowych, takich jak nazwy domenowe lub adresy IP. Ze względu na mnogość opcji oferowanych przez plik binarny tego narzędzia może zostać on użyty do przesłania dowolnego pliku z zaatakowanej maszyny na system atakującego za pośrednictwem jawnego połączenia TCP.
[ czytaj całość… ]

W

iększość użytkowników tego systemu nie ma pojęcia, co naprawdę oznacza średnie obciążenie systemu Linux. Bardzo często jest ono kojarzone tylko z wartością obciążenia procesora (CPU), a niestety tak nie jest. W rzeczywistości wartość ta reprezentuje średnią liczbę procesów (wątków), które w danym momencie: 1) wykonują pracę na procesorze 2) czekają w kolejce na dostęp do procesora 3) czekają na operacje wejścia / wyjścia (I/O) i nie tylko. I to właśnie trzeci punkt jest kluczowy i odróżnia Linuksa od wielu systemów Uniksowych. Dlatego wydając na przykład polecenie uptime, gdy wyświetlą się nam trzy średnie wartości dla 1, 5 i 15 minut:

05:58:34 up 12 days,  7:56,  1 user,  load average: 4.18, 3.13, 2.04

Nie możemy jednoznacznie powiedzieć, że dla systemu z dwoma wątkami procesora system jest przeładowany zadaniami obliczeniowymi.
[ czytaj całość… ]

Z

apper to mały program, który za pomocą ptrace() manipuluje stosem wektora pomocniczego (ang. auxiliary vector) formatu ELF (ang. Executable and Linkable Format), który posiada format tablicy w postaci par: „klucz – wartość” i jest przekazywany z jądra systemu do procesu w przestrzeni użytkownika, gdy program jest uruchamiany za pomocą funkcji systemowej execve(). Celem wspomnianego wektora (nazywanego również tablicą pomocniczą) jest dostarczenie programowi dodatkowych informacji konfiguracyjnych i środowiskowych, które są niezbędne lub przydatne dla programu w trakcie jego działania (np. jak argumenty linii poleceń czy zmienne środowiskowe – argc, argv, envp).
[ czytaj całość… ]

R

óżne formaty binarne (ang. Miscellaneous Binary Format) to mechanizm jądra Linuksa, który umożliwia systemowi rozpoznawanie i uruchamianie dowolnych formatów plików wykonywalnych za pomocą określonych programów w przestrzeni użytkownika, takich jak: interpretery, emulatory lub maszyny wirtualne. Głównym celem BINFMT_MISC jest rozszerzenie zdolności jądra do interpretowania, jak należy uruchomić dany plik, który nie jest natywnym formatem ELF (ang. Executable and Linkable Format) Linuksa. Użytkownik (z uprawnieniami administratora) może zarejestrować nowy format binarny w określonej ścieżce wirtualnego systemu plików procfs. Rejestracja polega na zdefiniowaniu kryteriów dopasowania plików, które mogą opierać się na: magicznych bajtach (ang. magic bytes) – sekwencji bajtów na początku pliku, które są charakterystyczne dla danego formatu; rozszerzeniu nazwy pliku – na przykład: .py, .sh, .pl itd. W ten sposób użytkownik może po prostu wpisać nazwę pliku, np. skrypt.py, a jądro automatycznie rozpozna jego format i przekaże go do odpowiedniego interpretera, tak jakby był natywnym plikiem wykonywalnym Linuksa (a skrypt nie musi nawet posiadać wewnątrz siebie definicji shebang).
[ czytaj całość… ]

S

hebang (ang. shebang line, bang path) (#!) na początku skryptu jest wymagany, ponieważ informuje jądro systemu operacyjnego (ang. kernel), jakiego interpretara należy użyć do wykonania danego pliku. Gry próbujemy uruchomić plik bezpośrednio (np. ./skrypt.sh), jądro sprawdza pierwsze bajty pliku. Jeśli znajdzie tam sekwencję #!, trakuje resztę linii jako ścieżkę do programu (interpretera), który ma zostać uruchomiony, przekazując mu nazwę skryptu jako argument. Historycznie to powłoka systemowa zajmowała się uruchamianiem skryptów, dopóki nie zostało to zmienione na jądro systemu przez Dennisa Ritche w 1980 roku. Kluczowy jest fakt, że jądro systemu nie przeszukuje zmiennej środowiskowej $PATH podczas obsługi shebang:

agresor@darkstar:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Zmienna $PATH jest używana przez powłokę (np. bash / dash), gdy wpisujemy dane polecenie (np. ls ), aby znaleźć odpowiedni plik wykonywalny. Uruchamiając polecenie śledzące konkretne wywołanie systemowe np. strace możemy zobaczyć jak wykonywane jest polecenie:

root@darkstar:~# strace -e execve cat /etc/hostname
execve("/usr/bin/cat", ["cat", "/etc/hostname"], 0x7ffdae655db8 /* 15 vars */) = 0
darkstar
+++ exited with 0 +++

Jądro systemu ma już pełną ścieżkę (/usr/bin/cat). Z kolei jeśli spojrzymy na kod źródłowy powłoki dash to w pliku exec.c znajdziemy informację o przeszukiwaniu zmiennej $PATH:

/*
 * Do a path search.  The variable path (passed by reference) should be
 * set to the start of the path before the first call; padvance will update
 * this value as it proceeds.  Successive calls to padvance will return
 * the possible path expansions in sequence.  If an option (indicated by
 * a percent sign) appears in the path entry then the global variable
 * pathopt will be set to point to it; otherwise pathopt will be set to
 * NULL.
 *
 * If magic is 0 then pathopt recognition will be disabled.  If magic is
 * 1 we shall recognise %builtin/%func.  Otherwise we shall accept any
 * pathopt.
 */

const char *pathopt;

int padvance_magic(const char **path, const char *name, int magic)

Dlatego jądro systemu, które aktualnie jako pierwsze obsługuje próbę uruchomienia pliku, działa na niższym poziomie i wymaga dokładnej, bezwzględnej (absolutnej) ścieżki do pliku wykonywalnego interpretera (np. /bin/bash, /usr/bin/python3). On, czyli interpreter dalej zajmuje się znalezieniem odpowiedniej ścieżki do programu. Gdybyśmy podali tylko #!bash jako shebang, jądro nie wiedziałoby, gdzie szukać pliku bash (czy jest w /bin, /usr/bin, /usr/local/bin, czy jeszcze gdzieś indziej). W wielu przypadkach możemy także zobaczyć shebang w formie:

#!/usr/bin/env bash

Tutaj pełną ścieżką jest /usr/bin/env. Program env również przeszukuje zmienną $PATH, aby znaleźć pierwszy argument, który mu podano (w tym przypadku: bash). Następnie env uruchamia znaleziony interpreter bash, przekazując mu resztę skryptu. Użycie programu env sprawia również, że skrypt jest bardziej przenośny między różnymi systemami (np. Linux, Unix), na których interpreter bash (lub python itp.) może znajdować się w różnych katalogach, ale program env jest prawie zawsze dostępny pod standardową ścieżką /usr/bin/env.

Więcej informacji: Shebang, env, PATH isn’t real on Linux