Paweł Goleń, blog

Cóż, pamiętam jak w czasie studiów pisaliśmy rozproszony program do łamania haseł (w ramach obliczeń równoległych i rozproszonych), więc wcale nie dziwi mnie, że tego typu techniki są wykorzystywane przy atakach brute force.

Standardowe zalecenia obrony przed atakami na SSH to:

• używanie złożonych haseł,
• zezwolenie na połączenia z określonych adresów IP,
• uruchomienie SSH na niestandardowym porcie,

Ja je trochę zmodyfikowałem (powtórzę się, kiedyś o tym pisałem już). Używanie kluczy zamiast haseł, w pliku konfiguracyjnym dla SSH wyłączam inne metody uwierzytelnienia, niż klucze. Poza tym ograniczam ilość prób uwierzytelnienia, które są dozwolone przed zerwaniem sesji (opcja MaxAuthTries, ustawiam na 1). Do tego dodaję ograniczenie ilości prób połączenia na port 22 w okresie czasu (opcja max-src-conn-rate, obecnie mam 3/60).

Co to daje? Po pierwsze łamanie hasła staje się bezcelowe, bo nie można go wykorzystać do uwierzytelnienia przez SSH. Po drugie ograniczenie ilości prób do 3 na minutę (z jednej stacji) skutecznie zmniejsza efektywność ataku. Dla przykładu plik Wordlist.txt dostępny z Cain&Abel zawiera 306706 elementów. Do sprawdzenia ich (z jednej stacji) potrzeba więc ponad 100 000 minut, dzień ma 1440, czyli jedna stacja będzie w mozole sprawdzać te elementy przez ponad 2 miesiące. Oczywiście, jeśli do ataku zostanie zaangażowanych więcej stacji, czas się skróci, ale nawet sprawdzenie wszystkich haseł nic nie da, bo... jak już wspominałem, nie używam haseł.

Swoją drogą przy ochronie przed atakami brute force ważne jest również to, ile czasu zajmuje sprawdzenie pojedynczego hasła. To, że hasła nie powinny być przechowywane w formie jawnej, jest już dość dobrze znanym faktem i z reguły wykorzystywane są różnego rodzaju hashe (np. md5, sha1). Lepszym rozwiązaniem byłoby jednak wywołanie funkcji skrótu wielokrotnie. Wówczas sam proces wyliczania hasha trwałby na tyle długo, że ilość możliwych do wykonania prób w jednostce czasu drastycznie by się zmniejszyła. O ile? To zależy od tego, ile tych iteracji byłoby wykonanych. Wykonanie 50 000 iteracji zajmuje (w przybliżeniu) 50 000 razy więcej czasu, niż jednej. W przybliżeniu, bo można próbować optymalizować to zadanie. Z kolei by utrudnić wykorzystanie rainbow tables, można dodać do całości jeszcze losowy salt. Po prostu "work factor" w czystej postaci.