O co chodzi w tej zasadzie?

Angielski termin security by obscurity można tłumaczyć jako bezpieczeństwo przez niejawność. Jest to pewien sposób na zwiększenie bezpieczeństwa systemu informatycznego. Polega na tym, że szczegóły dotyczące danego rozwiązania technicznego są ukrywane przed potencjalnymi atakującymi. Na przykład można ukryć zastosowaną implementację danego protokołu czy format przesyłanych danych. Po co? Aby skutecznie przeprowadzić atak najpierw konieczne jest rozpoznanie celu. Osoby próbujące inwigilować serwer znajdujący się pod opieką administratora muszą rozeznać włączone usługi, ich wersje czy porty na których one nasłuchują. Dopiero poznanie słabych stron konfiguracji danego hosta może pozwolić na ich ewentualne wykorzystanie w celu uzyskania dostępu do maszyny lub podniesienia już nabytych uprawnień.

Jest to takie podejście do tematu cyberbezpieczeństwa, które generalnie spotyka się raczej z przychylnym podejściem. Często też jest jednak negowane, szczególnie w przypadku kryptografii. Przed zastosowaniem security by obscurity w praktyce trzeba dobrze zrozumieć na czym to polega.

Przeniesienie SSH z portu 22 na inny to nie jest dobre security by obscurity

Niektórzy zalecają aby przenosić przynajmniej niektóre usługi ze standardowych portów na niestandardowe po to by utrudnić rozpoznanie działających na danej maszynie usług. Istnieje jednak kilka dobrych powodów, aby na przykład wcale nie przenosić portów SSH. Przyjrzyjmy się im żebyśmy następnym razem to my skutecznie zakończyli dyskusję, w której ktoś znowu tryumfalnie spróbuje puentować tezą o tym, że [cite]to jest security by obscurity więc nie ma o czym więcej rozmawiać[/i].

Security by obscurity nie jest ani dobre ani złe; problem polega na tym, że wiele osób nie ma pojęcia, kiedy powinno się to stosować. W tym większość ludzi, którzy mówią o tym najgłośniej.

„Prawdziwe” bezpieczeństwo przez niejawność

Security by Obscurity występuje wtedy, gdy ukrywasz, jak działa środek bezpieczeństwa, a nie gdy utrzymujesz jakąś jego część w tajemnicy. I tak, niektóre typy zabezpieczeń (np. szyfrowanie) mają dwa składniki: mechanizm i klucz. W szyfrowaniu mechanizmem jest algorytm, a kluczem jest… klucz właśnie. Pytanie brzmi: ukrywasz mechanizm, czy klucz? Jeśli ukrywasz, jak działa algorytm, korzystasz z security by obscurity. I to nie jest dobre.

Innymi przykładami złego rozumienia security by obscuritymogą być: przeskakiwanie częstotliwości w systemie radiowym, aby uniknąć podsłuchiwania, stosowanie kamuflażu na czołgach czy używanie limuzyn-wabików dla głów państw w niebezpiecznych obszarach. We wszystkich tych przypadkach mamy coś, co jest ukryte. Ukrywamy częstotliwość, z której korzystamy, ukrywamy położenie czołgu albo to w której limuzynie znajduje się prezydent. To nie jest nasza metoda. Tu nie ukrywamy mechanizmu. Oczywiście to nie tak, że są to nieskuteczne środki – przecież nawet jeśli twój wróg wie, że jesteś zakamuflowany gdzieś na pustyni, cała jego praca jest wciąż przed nim. Ale to nie jest security by obscurity. Mimo, że zmusza napastnika do wysiłku, sprawdzenia wszystkich możliwych częstotliwości.

I wszystkich portów, żeby znaleźć przeniesioną usługę SSH.

Korzyści

OK, zmieniłeś port SSH. Napastnik musi teraz przeskanować wszystkie porty i znaleźć nowy. Jasne, nie jest to zbyt trudne, ale wiele osób faktycznie to zrobi? Niewiele, ponieważ jest to kosztowne pod względem czasu i wysiłku. Krótko mówiąc, utrudniłeś wrogowi skuteczny atak, zmuszając go do głębszego sięgnięcia po jego zasoby.

Dopóki masz dobry klucz, ludzie mogą znać mechanizm. Kłódki na bramie też nikt nie zasłania.