SSH — hasła i uprawnienia

Pierwszy serwer, który wystawiłem do publicznego internetu, został zaatakowany po jakichś dwudziestu minutach. Nie przez kogoś, kto wiedział o jego istnieniu albo interesował się jego zawartością — przez automat, który skanuje cały internet bez przerwy, znajduje cokolwiek odpowiadającego na porcie zdalnego logowania i zaczyna zgadywać nazwy użytkowników i hasła. Znalazłem log następnego ranka: tysiące prób, alfabetycznie, niestrudzenie.

Ten log nauczył mnie o bezpieczeństwie więcej niż jakikolwiek kurs, który przeszedłem. Nie z powodu ataku — nie powiódł się — ale z powodu tego, co ujawnił o moim modelu myślowym. Myślałem o bezpieczeństwie jak o kwestii sekretów. Log zadawał inne pytanie: nie „co wiesz?", tylko „kim jesteś i co wolno Ci zrobić?".

Zmiana hasła to lekcja o uprawnieniach w przebraniu

Zacznij od czegoś, co wygląda banalnie. Jesteś zalogowany na serwerze i zmieniasz własne hasło. Działa i nic w tym nie wydaje się godne uwagi.

Teraz spróbuj zmienić cudze. System odmawia. Nie dlatego, że Twoje hasło było złe — już udowodniłeś, kim jesteś — tylko dlatego, że ta operacja należy do kogoś o większych uprawnieniach niż Twoje. Odmowa jest tu ciekawą częścią. System nie sprawdza, co wiesz; sprawdza, co wolno Twojemu kontu.

To są dwa osobne mechanizmy, a mylenie ich to najczęstszy błąd, jaki widuję u osób zaczynających z serwerami. Udowodnienie, kim jesteś, to uwierzytelnienie. Rozstrzygnięcie, co ta tożsamość może zrobić, to autoryzacja. Skradzione hasło pokonuje całkowicie to pierwsze i nie robi absolutnie nic z drugim. Dlatego pytanie „jak silne jest Twoje hasło?" jest znacznie mniej ciekawe niż „co może zrobić to konto, kiedy ktoś już jest w środku?".

Klucze zamiast haseł i dlaczego

Standardowa rada przy zdalnym logowaniu brzmi: przestań używać haseł i użyj pary kluczy. Oto, co to naprawdę znaczy, bez kryptografii.

Generujesz dwa dopasowane pliki. Jeden zostaje na Twoim komputerze i nigdy go nie opuszcza — to klucz prywatny. Drugi kopiujesz na serwer — to klucz publiczny i nie jest sekretem; mógłbyś go opublikować. Kiedy się łączysz, serwer stawia małą matematyczną zagadkę, na którą może odpowiedzieć tylko posiadacz prywatnej połowy. Twój komputer odpowiada. Sam klucz prywatny nigdy nie przechodzi przez sieć.

Liczy się praktyczna konsekwencja: atakujący zgadujący Twoje dane logowania nie ma czego zgadywać. Nie ma hasła, które można trafić. Tamte tysiące alfabetycznych prób z mojego logu stają się trwale bezcelowe, a logowanie hasłem wyłączyłem na tamtej maszynie tego samego ranka.

Uczciwy koszt: masz teraz plik, którego nie wolno Ci zgubić. Zgub klucz prywatny bez kopii i bez drugiej drogi wejścia, a zamkniesz sobie dostęp do własnego serwera równie skutecznie, jak zrobiłby to napastnik. Każdy, kto tak pracuje, albo już popełnił ten błąd, albo dopiero go popełni. Zabezpiecz klucz hasłem, trzymaj kopię w rozsądnym miejscu i — ten krok ludzie pomijają — zachowaj jedną alternatywną drogę do maszyny, która od niego nie zależy.

Konto, które widzi tylko jeden folder

Tu ta rzecz przestaje być teorią i zaczyna być czymś, co robię na każdej maszynie, którą konfiguruję.

Na serwerze trzymającym pliki domowników działa proces, który co noc kopiuje dane w miejsce backupu. Potrzebuje czytać pliki. Nie potrzebuje robić nic więcej. Nie działa więc jako administrator ani jako osoba, do której pliki należą. Działa na własnym koncie, które może czytać foldery objęte backupem i nie ma dostępu do niczego innego na tej maszynie.

Po co? Bo to zmienia wygląd złego dnia. Jeśli ten proces backupu zostanie przejęty — przez błąd w nim, pomyłkę w konfiguracji, cokolwiek — napastnik dziedziczy dokładnie jego uprawnienia i nic ponadto. Może czytać foldery, które ten proces mógł czytać. Nie sięgnie do biblioteki zdjęć, nie zainstaluje niczego, nie zmieni systemu, nie użyje maszyny do ataku na kogoś innego. Promień rażenia jest ograniczony z góry, decyzją, która zajęła dwadzieścia minut.

Ta zasada ma formalną nazwę i bardzo proste sformułowanie: daj każdemu kontu minimum potrzebne do wykonania jego zadania i nic więcej. To nie jest pomysł Linuksa — każdy poważny system tak działa — ale na Linuksie jest widoczna i regulowalna, co znaczy, że możesz faktycznie sprawdzić, czy zrobiłeś to dobrze.

Co faktycznie robię, po kolei

Cztery rzeczy, na każdej maszynie, zanim zbliży się do sieci, której nie kontroluję.

• Żadnego zdalnego logowania na konto administratora. Logujesz się jako zwykły użytkownik i dopiero podnosisz uprawnienia do konkretnej czynności, która tego wymaga. Ta jedna zmiana usuwa cel, w który mierzy każdy automatyczny skaner.
• Klucze zamiast haseł, a logowanie hasłem wyłączane dopiero potem — nie wcześniej, bo zamkniesz się na zewnątrz, co mi się zdarzyło.
• Automatyczne blokowanie adresów, które wielokrotnie się mylą. Nie dlatego, że zatrzyma to zdeterminowanego napastnika, ale dlatego, że usuwa stały szum tła i robi log czytelnym. Log, którego nie da się czytać, nie mówi Ci nic.
• Osobne, ograniczone konto dla wszystkiego, co zautomatyzowane, jak opisano wyżej.

I jedna rzecz, której nie robię, a warto ją wymienić, bo tę radę słyszy się wszędzie: nie zawracam sobie głowy przenoszeniem logowania na nietypowy port. Zmniejsza szum w logu, co jest przyjemne, i nie chroni przed niczym. Skaner sprawdzający wszystkie porty znajduje go w kilka sekund. Ukrywanie jest nawykiem porządkowym, a nie środkiem bezpieczeństwa, a mylenie tych dwóch rzeczy sprawia, że ludzie czują się bezpiecznie, będąc wystawionymi.

Cała lekcja kompresuje się do jednego zdania, które chciałbym usłyszeć przed tamtym pierwszym logiem. Bezpieczeństwo nie polega głównie na niewpuszczaniu ludzi. Polega na rozstrzygnięciu, z góry i na piśmie, do czego ktoś sięgnie, jeśli już wejdzie. Pierwsze to mur, a mury w końcu padają. Drugie to zestaw pokoi z zamkniętymi drzwiami i działa dalej po tym, jak mur padł.