Bezpieczeństwo rządowych stron - analiza

Zespół zadaniowy ds. ochrony portali rządowych opublikował wytyczne. Trudno stwierdzić, że to najlepsze rekomendacje, jakie można było przy okazji zaistniałych ataków wypracować.

Dokument przygotowany przez CERT.GOV.PL przypomina o elementarzu bezpieczeństwa IT. To ważne, ale chyba nie wystarczające. Przejdźmy jednak do treści dokumentu.

Błędne założenia dotyczące bezpieczeństwa

Jako niezbędne wskazane jest w nim ustanowienie stałych kontaktów - jak rozumiem, przez administratorów w domenie gov.pl - z Rządowym Zespołem Reagowania na Incydenty Komputerowe CERT.GOV.PL. Otóż stałe kontakty z tym zespołem istnieją od dawna. Zespół zainstalował w sieciach podmiotów administracji państwowej w ciągu kilku ostatnich lat kilkadziesiąt sond systemu ARAKIS-GOV. Nie dałoby się tego zrobić bez ustanowienia kontaktów z opiekunami tych systemów. Pytanie brzmi raczej: Jak wyglądają te kontakty i czy rekomendacja nie powinna wskazywać na sposoby ich poprawy?

Pomysły na filtrowanie ruchu sprowadzające się do kontroli aktywności internautów to grube nieporozumienie. To są kwestie dotyczące prawa do prywatności. Propozycja z wytycznych stanowi oczywisty atak na te prawa! Z pewnością skrytykują to organizacje pozarządowe. Zrobiła to już np. Fundacja Panoptykon. W warstwie technicznej też nie wygląda to najlepiej. Jeśli ktoś założył, że zebrane naprędce pomysły co do eliminacji takiego ruchu coś tu pomogą, to się grubo myli. Ataki, jakie wystąpiły, można przeprowadzić bez "ruchu anonimizowanego" i część z nich takimi właśnie była. Dodatkowo "wymuszenie ciągłej aktualizacji tych mechanizmów" to w praktyce apel o ciągły projekt badawczo-rozwojowy. Czy ktoś sobie z tego zdaje sprawę?

Apelowanie zaś o wprowadzenie możliwości "całkowitego filtrowania ruchu dotyczącego określonych typów pakietów lub całych protokołów" jest raczej niepotrzebne. Trudno sobie wyobrazić, aby w domenie gov.pl nie było takiej możliwości, to jedna z podstawowych funkcji zarządzania infrastrukturą dołączenia do internetu. Co gorsza, filtrowanie tego ruchu na urządzeniach znajdujących się bezpośrednio w infrastrukturze atakowanych nie spowoduje uniknięcia problemów, jakich doświadczyły serwery rządowe. Może być raczej powodem kolejnych kłopotów administratorów, jeśli urządzenia te przestaną działać w wyniku przeciążenia.

Szlaban na ataki hakerów

Pomysł przerzucenia odpowiedzialności za zapewnienie ciągłości działania na firmy hostujące i operatorów to sprytny zabieg, ale raczej z dziedziny zamiatania pod dywan. I, niestety, nic nie da. W rzeczywistości ataki nie znikną, bo większość hostujących firm sobie z nimi nie poradzi. Po prostu nie specjalizują się w tym. Chyba lepiej jednak poważnie porozmawiać z operatorami telekomunikacyjnymi, np. w ramach istniejącego Abuse-Forum, co można w takiej sytuacji zrobić. Chwilowe zwiększenie przepustowości, wykorzystanie mechanizmu "blackholingu", dołączanie się do więcej niż jednego operatora czy skorzystanie z usług przetwarzania w chmurze to tylko niektóre z pomysłów, jakie mogłyby pomóc. Zdecydowanie brakuje ich w zestawie wytycznych. To naprawdę dziwne w sytuacji, kiedy właśnie problem blokady serwisów był najbardziej dokuczliwy i najbardziej kojarzony z atakami.

Kolejnym przypadkom mają zapobiec dalsze rekomendacje. Pomysł z automatycznym - lub na żądanie - przełączeniem wersji witryn jest słuszny. Zachęcałbym jednak do unikania przełączania na informację "przerwa techniczna". Warto doprowadzić do tego, żeby serwis "statyczny" był zawsze dostępny w takiej konfiguracji, która maksymalnie redukuje możliwość skutecznego ataku. Dobrym pomysłem jest także wprowadzenie usługi rozkładającej ruch.