Ataki na usługę SSH stanowią od pewnego czasu masowe zjawiska. Atak możemy odkryć obserwując dzienniki / logi serwera. Typowy przebieg ataku wygląda następująco:

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.