Procedura skanowania serwerów pod kątem prostych haseł dla popularnych nazw użytkowników, a następnie (w przypadku pomyślnego zalogowania) próba eskalacji uprawnień poprzez błędy systemowe (zazwyczaj błędy w kernelu Linuksa) to stara i znana technika pozyskiwania kolejnych maszyn (zazwyczaj serwerów na konkretnych łączach). Poniżej przedstawiam małe zestawienie dla 1 adresu IP (maszyna znajduje się na terenie USA) z okresu stycznia 2009.
158 831 nieudanych prób przez 25 dni (6 różnych dni o dziwo bez żadnego logicznego powodu nie wykazały skanowań – 6, 8, 13, 14, 17, 18) czyli 6 353 prób dziennie i 264 próby na godzinę i 4.4 na minutę.
26 102 różne nazwy kont z czego 20 najczęściej występujących:
root – 23765 – 14.96%
admin – 995 – 0.63%
test – 910 – 0.57%
oracle – 530 – 0.33%
alexandr – 446 – 0.28%
christia – 393 – 0.25%
administ – 362 – 0.23%
ellen – 320 – 0.20%
ftp – 318 – 0.20%
deb – 316 – 0.20%
emil – 315 – 0.20%
alex – 304 – 0.19%
emma – 301 – 0.19%
arthur – 298 – 0.19%
art – 296 – 0.19%
bunny – 294 – 0.19%
danny – 293 – 0.18%
adm – 293 – 0.18%
games – 291 – 0.18%
contact – 291 – 0.18%
Skanowano z 47 różnych adresów IP:
66.216.20.105 – 62643 – 39.44%
125.206.243.126 – 34626 – 21.80%
222.97.189.61 – 9516 – 5.99%
200.217.70.70 – 6862 – 4.32%
121.15.226.230 – 4502 – 2.83%
61.82.8.156 – 4293 – 2.70%
211.48.190.67 – 3885 – 2.45%
209.40.199.130 – 3879 – 2.44%
69.162.73.178 – 3364 – 2.12%
190.34.194.162 – 2733 – 1.72%
117.21.248.199 – 2345 – 1.48%
59.160.172.208 – 2343 – 1.48%
203.177.2.70 – 2278 – 1.43%
98.126.44.210 – 2154 – 1.36%
210.157.14.127 – 1483 – 0.93%
194.79.130.36 – 1285 – 0.81%
221.239.143.115 – 1262 – 0.79%
89.188.127.174 – 1174 – 0.74%
72.20.1.122 – 1098 – 0.69%
220.196.75.120 – 1026 – 0.65%
79.127.124.131 – 902 – 0.57%
211.166.12.23 – 766 – 0.48%
72.13.190.246 – 660 – 0.42%
210.177.137.57 – 627 – 0.39%
150.188.87.53 – 599 – 0.38%
124.124.15.203 – 364 – 0.23%
122.199.254.7 – 314 – 0.20%
118.143.20.190 – 283 – 0.18%
174.129.151.40 – 244 – 0.15%
89.208.147.184 – 158 – 0.10%
204.225.175.224 – 138 – 0.09%
216.139.242.118 – 134 – 0.08%
212.117.189.86 – 132 – 0.08%
201.245.179.115 – 110 – 0.07%
65.37.224.4 – 99 – 0.06%
80.241.172.47 – 94 – 0.06%
72.46.123.190 – 94 – 0.06%
218.56.61.114 – 90 – 0.06%
87.255.70.154 – 71 – 0.04%
116.58.176.126 – 64 – 0.04%
150.187.50.53 – 38 – 0.02%
216.146.47.63 – 38 – 0.02%
212.174.255.65 – 20 – 0.01%
203.187.161.42 – 16 – 0.01%
58.72.213.212 – 14 – 0.01%
208.75.84.54 – 5 – 0.00%
67.z223.228.128 – 4 – 0.00%
Kraje, z których atakowano:
12 – 25.53% – United States
7 – 14.89% – China
5 – 10.64% – Republic Of Korea
3 – 6.38% – Japan
2 – 4.26% – Venezuela
2 – 4.26% – Canada
2 – 4.26% – Russian Federation
2 – 4.26% – Hong Kong
2 – 4.26% – India
1 – 2.13% – Turkey
1 – 2.13% – Republic Of Moldova
1 – 2.13% – Italy
1 – 2.13% – Colombia
1 – 2.13% – Luxembourg
1 – 2.13% – Islamic Republic Of Iran
1 – 2.13% – France
1 – 2.13% – Philippines
1 – 2.13% – Panama
1 – 2.13% – Brazil
Wnioski nasuwają się same:
- boty nadal skanują sieć w poszukiwaniu łatwych haseł, a skoro poszukują to znaczy, że metoda jest opłacalna czyli użytkownicy haseł nie pilnują,
- używać bardziej skomplikowanych haseł,
- jeśli jest możliwość skorzystać z systemu firewall i zezwalać dostęp z zaufanych adresów IP,
- dozbroić się w dodatkowe narzędzia automatycznie blokujące adres IP, który próbuje zgadywać hasła,
- wyłączyć możliwość logowania się bezpośrednio na konto root,
- aktualizować kernel (i nie tylko).
7 komentarzy do
16 lutego, 2009 o godzinie 01:10
Posiadacie może jakieś statystyki dotyczące skanowania usługi SSH w poszukiwaniu słabych kluczy wygenerowanych przy pomocy dziurawego OpenSSL’a w Debianie?
17 lutego, 2009 o godzinie 00:10
Niestety błędna próba logowania za pomocą kluczy nie jest odnotowana w logach i osobiście takich danych nie posiadam. A też jestem ciekaw :]
19 lutego, 2009 o godzinie 01:13
Niestety przez to skanowanie mocno ucierpiałem. Wszędzie mam ssh poblokowane ssh po ip. Ale akurat pech chciał, że był serwer do nauki z publicznym ssh. I było kilku uczniów co męczyło ten serwer. No i ktoś (jak zwykle nikt się nie przyznaje) założył konto test o haśle test.
Ktoś się zalogował z francji, zaraz wylogował, potem się zalogował z rosji i kombinował jak tu roota zdobyć. Jako że z konta test nie było jak się zalogować na roota i system z łatami był na bierząco to guzik zrobił.
Ale niestety nauczka musi być i koleś zrobić atak na serwery w rosji, wygenerował ruch na poziomie kilku MB/s pakietów UDP na port 0. ISP padł, sprawa trafiła na policję i przez to się musiałem po policji walać.
20 lutego, 2009 o godzinie 03:17
tak czy inaczej, warto zawiesić sshd na jakimś nieużywanym wysokim porcie, boty skanują tylko domyślne porty i nie szukają gdzie indziej. Kto ma mieć możliwość zalogowania się, ten będzie znał port. Reszta nie musi. I to chyba jest kierunek obok odfiltrowania wszystkiego poza znanymi lokalizacjami.
20 lutego, 2009 o godzinie 11:48
Uruchamianie sshd na wysokich portach nie zawsze jest możliwe, szczególnie jeżeli trudno jest określić z jakich sieci będzie dostęp do systemu (często się zdarza, że niestandardowe porty są filtrowane).
Warto moim zdaniem zastanowić się nad uruchomieniem czegoś na kształt sshdfilter’a – po trzech (albo więcej lub mniej) nieudanych próbach logowania adres IP wpada na czarną listę. Należy wtedy tylko pamiętać aby nie logować się po pijaku albo na mocnym kacu, gdzie możemy się łatwo pomylić wpisując hasło. ;-)
Pomijam kwestię autoryzacji za pomocą kluczy.
20 lutego, 2009 o godzinie 12:20
yzzuf: tak jak piszesz działa fail2ban. Sprawdza ilość prób z danego adresu IP i dropuje na iptablesach. Ale tutaj można wpaść na inny problem. Jeżeli 100k botów wykona tylko 3 próby logowania na bota, to żaden filtr ich nie wyśledzi.
20 lutego, 2009 o godzinie 12:24
Wszystko tak naprawdę zależy od twoich potrzeb i to one powinny decydować o środkach które zastosujesz.
Botom też można utrudnić życie ograniczając ilość możliwych logowań na sekundę, minutę, godzinę… Ale do końca to też nie rozwiązuje problemu.