Jak chronić serwery SSH przed atakami?
Obserwujemy znaczną ilość prób włamań w dziennikach systemowych serwera SSH. Co możemy zrobić, aby lepiej chronić się przed atakami?
Aug 27 06:10:21 r1 sshd[5458]: Illegal user test from 192.168.100.2
Aug 27 06:10:26 r1 sshd[5460]: Illegal user guest from 192.168.100.2
Aug 27 06:10:22 r1 sshd[5462]: Illegal user admin from 192.168.100.2
Aug 27 06:10:28 r1 sshd[5464]: Illegal user admin from 192.168.100.2
Aug 27 06:10:23 r1 sshd[5466]: Illegal user user from 192.168.100.2
Jeżeli przejrzymy dzienniki systemowe, prawdopodobnie zobaczymy duża liczbę prób logowania się na konta o nazwach test, root, guest, admin, administrator. Atak słownikowy na usługę SSH, odnajduje przeważnie proste hasła, na kontach ze standardowymi nazwami i serwerach SSH uruchomionych na standardowych portach. W procesie zabezpieczeń przed tego typu atakami, koniecznością jest regularne sprawdzanie dzienników systemu i zapory ogniowej.
Dział Internet Storm Center organizacji SANS przedstawił raport z którego wynika, że ataki słownikowe na usługę SSH są coraz bardziej skoordynowane i przeważnie pochodzą z rozproszonych systemów. Istnieją jednak skuteczne metody chroniące przed takimi atakami.
Dobrym zwyczajem jest ograniczanie dostępu do usługi SSH, wyłącznie dla wybranych sieci/adresów IP. Jeżeli jest to możliwe, warto ograniczyć logowanie SSH dla specyficznych kombinacji par użytkownik/host. Nie zawsze istnieje taka możliwość, szczególnie gdy mamy do czynienia z użytkownikami przemieszczającymi się. Jeżeli jednak konieczne jest pozostawienie usługi SSH otwartej na świat, warto przenieść ją na port niestandardowy. Taka zmiana w niczym nie przeszkadza, a radykalnie zmniejszy ilość ataków. W przypadku wersji OpenSSH pracującej z systemem Linux/Unix, wystarczy zmienić deklarację "Port" w pliku /etc/ssh/sshd_config.
Niektóre zapory ogniowe posiadają funkcjonalność ograniczania dostępnej ilości błędnych prób logowania z indywidualnego systemu. Wykorzystanie programu fail2ban umożliwi automatyczne zablokowanie atakujących adresów IP, po przekroczeniu ustalonej liczby prób logowania. Alternatywnym rozwiązaniem jest wykorzystanie narzędzia tcpwrappers lub portsentry (http://sourceforge.net/projects/sentrytools/ ).
Dobrym pomysłem jest wyeliminowanie wszystkich zbędnych kont w systemie oraz wykorzystanie niestandardowych nazw dla kont utrzymywanych. Sytuacją idealną będzie odgórne przydzielenie każdemu użytkownikowi mocnego hasła, uniemożliwiającego przeprowadzenie pomyślnego ataku słownikowego na usługę.
Wraz ze wzrostem rozproszonych, koordynowanych ataków na SSH, bezpieczeństwo danego użytkownika/hasła maleje. Jeżeli nie ma możliwości ograniczania dostępu do SSH dla znanego zakresu adresów IP, ostateczną czynnością będzie edukacja użytkowników oraz wprowadzenie wymogu uwierzytelniania, bazującego na kluczach.
Komentarze (4)
Braklo bardzo istotnej rzeczy - prawdziwego wykorzystania funkcji jakie daje nam SSH. Chodzi o autoryzacje po kluczach dsa/rsa. U mnie w firmie od kilku lat nie uzywamy hasel. Wogole :) SSH skonfigurowane jest tak, aby odrzucac automatycznie jaki kolwiek request za ktorym nie stoi proba autoryzacji po kluczach rsa/dsa. SSH nalezy skonfigurowac w taki sposob, aby mogli logowac sie tylko konkretni userzy (opcja AllowUsers), ktorzy maja wygenerowane klucze (prywatny, chroniony haslem + publiczny, znajdujacy sie w ich katalogu domowym .ssh). Takie rozwiazanie jest o wiele lepsze niz silne hasla. Wszak.. mozemy zadecydowac, zeby klucze mialy wielkosc np. 4096 bitow...
Brakuje mi w tym artykule konkretów. Chociaż jednego przykładu konfiguracji, wpisu w pliku konfiguracyjnym. Ciekawym rozwiązaniem wydaje się być zablokowanie logowania hasłowego na korzysz logowania z kluczem. Może to być jednak problematyczne w sieciach gdzie jeste duża liczba użytkowników logujących się przez terminal.
Dziękuję za komentarz wskazujący możliwość zastosowania metody Port Knocking. Przedstawiona technika może znakomicie uzupełniać porady przedstawione w artykule.
brakuje mi w tej poradzie co najmniej 2 kwestii: - wyłączenie logowania na konto administratora i innych użytkowników uprzywilejowanych - zastosowanie port knocking-u (np. [[http://doorman.sourceforge.net]]) jako niezłej metody "utwardzającej" serwer SSH. K.
- Skanery WiFi na platformę Android
- Prawo Moore’a zagrożone?
- Bezpieczeństwo WiFi - bezprzewodowe testy penetracyjne
- Wirtualizacja: obsługa SMB na czterech U
- Prawdziwe powody powstania Microsoft Open Technologies
- MDT 2012: Microsoft aktualizuje Deployment Toolkit
- Open source: zmierzch ery GPL? Nie do końca...
- ROVER - prosty sposób na słabość BGP?
- Zaawansowane stacje Wi-Fi Ruckus Wireless
- Rozstanie z Javą nie będzie proste
Reklama
Huawei celuje w rynek biznesowy
Huawei nieustannie rozwija się jako dostawca infrastruktury dla branży telekomunikacyjnej. W tym roku chiński koncern zamierza umocnić swoją pozycję również na rynku rozwiązań Enterprise.
Polecane
Koniec Windows XP początkiem problemów?
Microsoft oficjalnie potwierdził, że za dwa lata definitywnie zakończy się era Windows XP - systemu operacyjnego,...
Spokój i luz administratora
Wymagania wobec pracowników działów IT rosną proporcjonalnie do stopnia rozwoju teleinformatyki. Oczekuje się, że...