Masowe skanowanie usługi SSH pod kątem prostych haseł do popularnych loginów jest znane i wykorzystywane już od dłuższego czasu. Zarażone komputery próbują zalogować się do systemu na określone konta użytkowników używając haseł takich samych jak loginy, najpopularniejszych słów czy stosując proste przekształcenia, w których hasło jest pisanym od tyłu loginem lub do loginu dodawane są cyfry 123. Po przejęciu konta, w systemie wykonywany jest szereg akcji umożliwiających ponowny powrót do konta oraz aktywacja programów, które stają się częścią sieci botnet. A potem już standardowo SPAM, ataki DDoS itp.
W sieci można odnaleźć wiele skryptów, których zadanie polega na analizie przychodzących prób połączeń do usługi SSH. Jeśli ilość nieudanych prób z danego adresu IP przekroczy próg (zazwyczaj ustawiony na 4 próby), skrypt automatycznie blokuje na firewallu dostęp tego IP do maszyny, najczęściej na jakiś czas. Jednak skanujący z racji faktu, że coraz więcej administratorów stosowało taką taktykę obronną, wzięli się na sposób. Aktualnie jak donosi Nazar Aziz z jednego adresu IP próba zalogowania podejmowana jest jedynie 3-krotnie. Następne logowania odbywają się z innego adresu IP. Dzięki temu możliwe jest ominięcie blokad i dalsze skanowanie. Do tego celu wykorzystywana jest zapewne armia botów, które prawdopodobnie wymieniają się informacjami na temat tego, które hosty i jakie loginy były już skanowane. Ja przejrzałem swoje logi z nieudanych prób logowań i nie zauważyłem tego trendu ale jak wiadomo internet jest przepastny i zapewne nowomoda dotrze także i do mnie :]
Całkiem przy okazji wygenerowałem małe statystyki dotyczące tychże skanów. W okresie od 12 lutego 2008 do 14 lipca 2008 mój system odnotował 943 308 nieudanych prób logowania, co po uśrednieniu wynosi około 6200 dziennie czyli 262 na godzinę czyli 4 na minutę. Należy dodać, że system ten obsługuje większą ilość adresów IP (ponad 100) co znacząco wpływa na wyniki. Łącznie testowanych było 21 918 różnych loginów.
Poniżej zestawienie setki najczęściej testowanych loginów do kont. Co ciekawe pojawiają się tam loginy stricte polskie takie jak choćby gosc czy proba (zapewne od gość i próba :). Statystyki potwierdzają starą jak świat prawdę: Nie loguj się nigdy jako root (raczej via su / sudo z konta zwykłego użytkownika) przez ssh, a hasło posiadaj przedziwne…
1 | 165252 | 17.52% | root
2 | 17050 | 1.81% | admin
3 | 16471 | 1.75% | test
4 | 8888 | 0.94% | a
5 | 8693 | 0.92% | guest
6 | 6299 | 0.67% | user
7 | 5735 | 0.61% | oracle
8 | 2995 | 0.32% | mysql
9 | 2752 | 0.29% | tester
10 | 2688 | 0.28% | student
11 | 2471 | 0.26% | postgres
12 | 2460 | 0.26% | webmaster
13 | 2437 | 0.26% | info
14 | 2325 | 0.25% | temp
15 | 2202 | 0.23% | webadmin
16 | 2133 | 0.23% | ftp
17 | 1996 | 0.21% | alex
18 | 1952 | 0.21% | apache
19 | 1876 | 0.20% | web
20 | 1807 | 0.19% | sales
21 | 1722 | 0.18% | paul
22 | 1704 | 0.18% | john
23 | 1690 | 0.18% | linux
24 | 1684 | 0.18% | testing
25 | 1663 | 0.18% | michael
26 | 1638 | 0.17% | amanda
27 | 1633 | 0.17% | mail
28 | 1622 | 0.17% | david
29 | 1557 | 0.17% | test1
30 | 1520 | 0.16% | teste
31 | 1499 | 0.16% | ftpuser
32 | 1420 | 0.15% | www
33 | 1418 | 0.15% | backup
34 | 1389 | 0.15% | richard
35 | 1378 | 0.15% | adm
36 | 1349 | 0.14% | administrator
37 | 1345 | 0.14% | postfix
38 | 1338 | 0.14% | news
39 | 1307 | 0.14% | test2
40 | 1299 | 0.14% | dan
41 | 1289 | 0.14% | nobody
42 | 1288 | 0.14% | adam
43 | 1282 | 0.14% | danny
44 | 1269 | 0.13% | username
45 | 1264 | 0.13% | proba
46 | 1222 | 0.13% | robert
47 | 1203 | 0.13% | mike
48 | 1198 | 0.13% | master
49 | 1196 | 0.13% | httpd
50 | 1196 | 0.13% | tomcat
51 | 1194 | 0.13% | games
52 | 1150 | 0.12% | clamav
53 | 1150 | 0.12% | nagios
54 | 1142 | 0.12% | www-data
55 | 1127 | 0.12% | steven
56 | 1113 | 0.12% | office
57 | 1102 | 0.12% | demo
58 | 1095 | 0.12% | pgsql
59 | 1079 | 0.11% | students
60 | 1061 | 0.11% | toor
61 | 1056 | 0.11% | upload
62 | 1053 | 0.11% | gosc
63 | 1051 | 0.11% | support
64 | 1008 | 0.11% | matt
65 | 999 | 0.11% | dave
66 | 997 | 0.11% | gast
67 | 992 | 0.11% | rpm
68 | 978 | 0.10% | angel
69 | 955 | 0.10% | fax
70 | 949 | 0.10% | nick
71 | 941 | 0.10% | mailman
72 | 931 | 0.10% | shell
73 | 930 | 0.10% | library
74 | 925 | 0.10% | cyrus
75 | 917 | 0.10% | andrew
76 | 917 | 0.10% | james
77 | 917 | 0.10% | bin
78 | 913 | 0.10% | ben
79 | 910 | 0.10% | ftptest
80 | 907 | 0.10% | wwwrun
81 | 903 | 0.10% | soporte
82 | 901 | 0.10% | test123
83 | 901 | 0.10% | samba
84 | 897 | 0.10% | jack
85 | 896 | 0.09% | alan
86 | 886 | 0.09% | brian
87 | 879 | 0.09% | adrian
88 | 869 | 0.09% | operator
89 | 867 | 0.09% | eric
90 | 862 | 0.09% | shop
91 | 860 | 0.09% | martin
92 | 860 | 0.09% | frank
93 | 853 | 0.09% | http
94 | 844 | 0.09% | admins
95 | 843 | 0.09% | lp
96 | 826 | 0.09% | daniel
97 | 826 | 0.09% | nicole
98 | 822 | 0.09% | george
99 | 819 | 0.09% | irc
100 | 818 | 0.09% | server
4 komentarze do
17 lipca, 2008 o godzinie 10:10
„W sieci można odnaleźć wiele skryptów, których zadanie polega na analizie przychodzących prób połączeń do usługi SSH. Jeśli ilość nieudanych prób z danego adresu IP przekroczy próg (zazwyczaj ustawiony na 4 próby), skrypt automatycznie blokuje na firewallu dostęp tego IP do maszyny, najczęściej na jakiś czas.”
Do tego nie potrzeba żadnych skryptów tylko zwykłe iptables-y.
17 lipca, 2008 o godzinie 13:22
Pewnie, jest takie doskonałe narzędzie fail2ban które to robi, ale w tym przypadku co Ci po nim, jeżeli z jednego adresu IP masz 3 nieudane próby, z następnego adresu IP następne 3 próby i tak dalej. Skrypt nigdy nie zauważy 4 błedów z jednego adresu IP, i o to chodzi.
17 lipca, 2008 o godzinie 13:47
Zaznaczyłem, tylko że do blokowania jakiegoś IP po kilku próbach połączenia to wystarczy samo iptables, a nie jakieś skrypty. Ot tyle i koniec.
18 lipca, 2008 o godzinie 00:16
Oczywiście, że masz LCFie rację, jednakże 1 linijka z odpowiednim wpisem iptables wpisana do pliku to już skrypt :} A metod jest oczywiście jak podkreśliłem wiele, tym bardziej, że możemy chcieć otrzymywać powiadomienia o zaistniałej akcji, dopisywać sobie do bazy danych dla statystyk, prowadzić bardziej szczegółowe dochodzenia itd. A czy będzie to za pomocą firewalla i jego modułów typu choćby „recent” czy za pomocą tcpwrapperów nasłuchujących na bieżąco i uruchamiających firewalla lub blokujących przez natywne funkcje wrapperów czy być może za pomocą skryptów/programów/daemonów analizujących pliki z logami – nie ma to specjalnie znaczenia, gdyż sednem tego posta jest fakt, że wszystkie te metody w prawie wszystkich wypadkach zawiodą bo bazują na adresie IP. Ponadto już całkiem na marginesie blokowanie za pomocą jedynie iptables ma także swoje wady choćby takie jak brak rozpoznania połączenia zaakceptowanego oraz odrzuconego przy założeniu, że opieramy się jedynie na metodach ilościowych :}
pozdrawiam serdecznie :}