Testowanie publicznych projektów na produkcji w rządowych polskich domenach to bardzo kiepski pomysł. Internet wszystko zapisuje, więc na Twitterze znalazła się informacja o podmienionej polskiej subdomenie webcad.pgi.gov.pl przez niejakich hakerów z grupy GhostSquadHack, odpowiedzialnych za cyberataki na Fox News, CNN, Bank Centralny, wojskowe instytucje USA i Izraela i afgańskiego CEO Twittera. Ich poczynania można śledzić na tym profilu na Twiterze.
Subdomena webcad.pgi.gov.pl należąca do Państwowego Instytutu Geologicznego i Badawczego w marcu 2018 roku wyglądała jeszcze tak:
Właściwie nic poza „hello world” nie znajdowało się tam ciekawego. Ale już przez około miesiąc, czyli od pierwszych tygodni czerwca i jeszcze do wczoraj, strona webcad.pgi.gov.pl wyglądała tak:
Nie mamy pojęcia, co testowano lub co planowano wdrożyć pod subdomeną webcad.pgi.gov.pl. Ktoś zapomniał o porzuconej części systemu informatycznego lub nie dołożył wszelkich starań, aby zaktualizować backend. Niemniej rządowa administracja informatyków zaliczyła wizerunkową wpadkę. Miejmy tylko nadzieję, że na serwerze nie przechowywano żadnych poświadczeń do innych usług rządowych w plikach tekstowych lub innych dokumentów — i że do żadnych wycieków informacji nie doszło.
Szybkie zapytanie w wyszukiwarce Shodan pokazuje skalę problemu. Zwrócona odpowiedź pokazuje 47 innych stron internetowych ze słowem „hacked” lub „hacked by”, z czego:
- 28 postawionych jest na webserwerze IWS, 6 na Apatche i 2 na LiteSpeed
- 30 zaparkowano w home.pl, 8 w ovh.pl, 4 w nazwa.pl i 2 w IQ.pl
- 24 ze zhakowanych stron posiada certyfikat SSL (niekoniecznie ważny).
To tylko niektóre przykłady znalezione w 5 minut od uruchomienia Shodana i wyszukiwarki Google. Jest tego znacznie więcej i tak naprawdę nie jest to nic, o czym nie wiedziałaby osoba zajmująca się bezpieczeństwem. Widok podmienionych stron nie robi wielkiego wrażenia, ale rządowe domeny to zupełnie coś innego.
Jak prawidłowo zabezpieczyć stronę WWW przed atakiem?
Na to nie ma mocnych. I nie ma większego znaczenia, czy strona napędzana jest przez WordPressa, Jomlę, czy uważanego za bardzo bezpiecznego Drupala. Niezaktualizowane CMS-y, serwery WWW, baz danych i PHP to proszenie się o kłopoty.
1. O ile to możliwe zaktualizuj rdzeń CMS-a oraz wszystkie moduły do najnowszej wersji. Szczególnym zainteresowaniem hakerów cieszy się WordPress.
2. Zaktualizuj serwer http, serwer bazy danych i serwer php (jeżeli sam zarządzasz całym majdanem).
3. Rozważ zamaskowanie prawdziwego adresu IP serwera za siecią CDN (np. CloudFlare). Dzięki temu unikniesz wielu ataków oraz automatycznie zablokujesz dostępu botom i spamerom do strony.
4. Rozważ zainstalowanie WAF-u bazującego na mod_security. Zabezpieczysz w ten sposób stronę przed „niepoprawnym” ruchem internetowym.
5. Jeśli zarządzasz serwerem korzystaj z najnowszych wersji kernela, najlepiej już z łatką grsecurity, która chroni przed zagrożeniami 0-day.
6. Wyłącz logowanie na konto root poprzez hasło i zastąp je logowaniem z wykorzystaniem kluczy.
7 Jeśli musisz używać konta root, zaloguj się do serwera na konto o niższych uprawnieniach, a później przełącz się na roota.
8. Skonfiguruj iptables lub alternatywny CSF.
9. Do ochrony przed atakami brute-force zainstaluj fail2ban.
10. Do zalogowania się do kont FTP stosuj konto użytkownika, a nie roota.
11. Na hostingu współdzielonym stosuj odrębne konta FTP do każdej strony.
12. Dla serwerów VPS, serwerów dedykowanych, kont FTP, loguj się przez SFTP.
13. Zadbaj o bardzo częste wykonywanie kopii zapasowych plików strony i bazy danych. Nigdy nie wiadomo, kiedy coś zepsujesz (lub ktoś ci zepsuje) i będziesz potrzebować backupu sprzed godziny.
14. Ostatnia uniwersalna wskazówka dla wszystkich zarządzających stronami internetowymi — tak jak my to zrobiliśmy, wrzuć na serwer FTP ten prosty skrypt PHP, następnie dodaj go do crona (aby wykonywał się np. raz dziennie), a ochroni cię przed nieautoryzowanym zmodyfikowaniem plików strony. Powiadomienia o usuniętych, dodanych i zmodyfikowanych plikach dostaniesz na maila:
