Zacząłem od notatnika. Nie od edytora tekstu czy pliku markdown, ale od spiralowego, papierowego zeszytu wypełnionego komendami, których nie rozumiałem. Spisywałem ls, grep, find, chmod oraz nmap. Warstwa po warstwie zapełniałem strony składnią, traktując Linuxa i cyberbezpieczeństwo jak testy ze słownictwa, jak gdyby znajomość większej liczby flag niż u innych czyniła mnie kompetentnym. Potrafiłem płynnie kopiować składnię. Gdy jednak poproszono mnie o wyjaśnienie, dlaczego dana komenda zwróciła konkretny wynik, milknąłem. Ta cisza była problemem.

Pułapka notatnika

Notatnik dawał złudzenie postępu. Każda kolejna strona przybywała z nowym atramentem: find / -name "*.conf", nmap -sV, grep z potokami i wyrażeniami regularnymi. W samouczkach takie podejście wydaje się działać. Prezenter wpisuje komendę, ekran pokazuje oczekiwany wynik, a ty potakujesz głową. Czujesz się kompetentny, bo twój terminal wygląda identycznie jak ich. Ale ta kompetencja jest pożyczona. Należy do osoby, która zaprojektowała ścieżkę samouczka.

Rzeczywiste środowiska nie trzymają się scenariuszy. Serwer odrzuca twoje połączenie SSH, mimo że port jest otwarty. Skrypt kończy się błędem „permission denied”, mimo że wcześniej uruchomiłeś chmod +x. Skanowanie raportuje port jako przefiltrowany (filtered) zamiast otwartego, i teraz musisz zdecydować, czy oznacza to regułę zapory sieciowej, kontrolę opartą na hoście, czy system zapobiegania włamaniom (IPS), który po cichu odrzuca twoje zapytania. W takich momentach zapamiętywanie składni zawodzi, ponieważ problemem nie jest zapomniana komenda. Problemem jest system, którego nie rozumiesz.

Kopiowanie to nie nauka

Istnieje różnica między podążaniem za samouczkiem a rozwiązywaniem problemu. Kiedy kopiujesz, przechodzisz od kroku A do kroku B na czyjejś mapie. Gdy coś odbiega od normy, zamierasz, ponieważ twój model mentalny jest pusty. Wiesz, że chmod 755 zmienia uprawnienia, ale nie potrafisz wyjaśnić, dlaczego system wciąż blokuje dostęp, gdy plik znajduje się na zamontowanym systemie plików z flagą noexec. Wiesz, że nmap potrafi skanować porty, ale nie potrafisz zinterpretować, dlaczego skanowanie SYN zwraca inne wyniki niż skanowanie connect, gdy w grę wchodzi inspekcja stanowa (stateful inspection).

Nie uczyłeś się Linuxa ani sieci. Uczyłeś się naśladować.

Zmień sposób zadawania pytań

Zmieniłem jedną rzecz. Przestałem pytać: „która komenda to naprawi?”, a zacząłem pytać: „co system właściwie robi?”. Ta zmiana była niewygodna, bo spowalniała moje postępy. Ale zadziałała.

Weźmy uprawnienia do plików. chmod to nie modlitwa do magicznych liczb. To jedynie wierzchnia warstwa tego, jak jądro pośredniczy w dostępie do inode'ów. Kiedy zrozumiesz, że system operacyjny sprawdza twoje efektywne ID użytkownika (effective user ID) względem właściciela pliku, grupy i innych użytkowników, liczby nabierają sensu. Kiedy dowiesz się, że uprawnienia do katalogu kontrolują, czy możesz przejść przez ścieżkę lub wymienić jej zawartość, przestaniesz się zastanawiać, dlaczego możesz odczytać plik, ale nie możesz do niego dotrzeć. Uświadamiasz sobie, że uprawnienie do wykonywania (execute) w katalogu nie polega na uruchamianiu programów, lecz na możliwości dostępu do znajdujących się w nim inode'ów. Nagle chmod nie wymaga już zapamiętywania. Wymaga kontekstu.

Podstawy sieciowe działają tak samo w przypadku nmap. Skanowanie portów to nie lista otwartych drzwi; to rozmowa składająca się z pakietów. Kiedy opanujesz trójetapowy proces nawiązywania połączenia TCP (three-way handshake), zrozumiesz, dlaczego skanowanie SYN wymaga uprawnień do surow