22:42
18/6/2017
18/6/2017
Oto analiza jednego z czytelników na podstawie własnych logów.
TOP15 prezentujemy poniżej:
1 root 10934 2 admin 1137 3 ubnt 110 4 user 103 5 support 90 6 pi 79 7 git 69 8 ftp 64 9 mysql 60 10 default 59 11 monitor 58 12 0 57 13 usuario 55 14 test 51 15 ftpuser 44
Posłuchaj jednego z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
Na swoich routerach mam tego od groma prób… dlatego ustawiłem sobie nawet regułę odrzucania po 3 próbach. Zamieszczam, jakby ktoś chciał:
/ip firewall filter
add action=drop chain=input comment=”podziekujemy jeszcze wlamywaczom ssh” dst-port=22 protocol=tcp src-address-list=wlamywacze
add action=add-src-to-address-list address-list=wlamywacze address-list-timeout=30d chain=input connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_podejrzani
add action=add-src-to-address-list address-list=ssh_podejrzani address-list-timeout=2m chain=input connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_users
add action=add-src-to-address-list address-list=ssh_users address-list-timeout=1m chain=input connection-state=new dst-port=22 protocol=tcp
Przez 45 dni od ostatniego restartu (update) logi wyglądają tak:
– 12570 pojedyńczych prób logowań (ale wliczając w to udane logowania adminów, których było jakieś ~20)
– 2207 podwójnych nieudanych prób logowań
– 341 potrójnych nieudanych prób logowań równoznacznych z banem
– 41856 prób połączenia od zbanowanych hostów
Trochę ciężko tak walczyć w pojedynkę…
^ mikrotik dla niewtajemniczonych
Co takiego prowadzisz, że masz tyle prób włamań?
Sieć komputerową w pewnej instytucji oświatowej z lokalnym webserwerem, serwerem danych i systemem BMS :)
Wystawiłeś serwer ssh na domyślnym porcie?
Po co?
Choćby dlatego, że często pracuję offsite, a prawdopodobieństwo złamania hasła jest dużo mniejsze od prawdopodobieństwa odkrycia portu do ssh. Dodatkowo wysokie porty nie za dobrze gadają z każdej sieci :)
A nie boisz się jakiegoś 0-daya na serwer ssh? ;-)
@Kamil:
To ma być dużo? Kiedyś zlogowałem 650k w ciągu 12h a też nie uważam by było to jakoś kosmicznie dużo. Oczywiście natychmiast dodałem regółę odrzucającą po błędnych próbach.
Lukasz032
Dlaczego nie chcesz sobie wprowadzić autoryzacje logowania po adresie , adresach IP, ?
Chyba najskuteczniejsze rozwiązanie bo odsiało by ci z automatu jakieś 99% .
Ciągle żyjesz w przekonaniu, że zmiana portu SSH nie ma sensu bo to security by obscurity. Prawa jest jednak taka, że zmiana portu nie ochroni cię tylko przed atakiem wycelowanym w Ciebie konkretnie. Ochroni Cie natomiast przed shodanem i skryptami skanujacymi.
Jak wolisz – igrasz z ogniem i tylko czekasz na 0-day.
Akurat ten host ssh to tylko brama brzegowa, jedyne, co można sobie stamtąd zrobić, to w ograniczonym zakresie pochodzić po sieci, ewentualnie zrestartować któryś RB przez CAPsMAN. Żeby wejść już gdziekolwiek na serwery, to najpierw trzeba sobie zestawić SSTP.
A słyszałeś o port knocking? SSH wciąż na domyślnym porcie ale nie połączysz się zanim nie zapukasz sobie znaną sekwencją.
Słyszałem i nawet aktywnie wykorzystuję, chociaż szczegóły konfiguracji tego konkretnego wdrożenia to wiedza ściśle pracownicza :)
Dobrze jest też zmienić port serwera SSH na jakiś wysoki, niestandardowy. To skutecznie odsiewa 90% botów.
True, chyba że to serwer SFTP (FTP over SSH), a zmiana portu nie bardzo wchodzi w grę z powodu tego, że albo sieci klientów nie pozwalają na połączenia na egzotyczne porty, albo nie są w stanie ich zapamiętać i nie potrafią się połączyć klientem.
A może dodamy do tego port-knocking? ;)
… i wyłączyć logowanie hasłem, zostawić tylko certyfikatem…
BTW: w OS X w wersji serwerowej bodajże domyślnym sposobem uwierzytelnienia jest keyboard-interactive :D
To najprostsze i najskuteczniejsze rozwiązanie. Hasło na root’a mogłbym opublikować, a i tak nikt poza mną nie zaloguje się na żadne konto. :)
Możliwość logowania się hasłem to samobójstwo. Ostatnio w logach OSSEC zauważyłem swoje hasło z przed kilkunastu lat. Nawet nie pamiętam już gdzie mogło być użyte (rejestruję wyłącznie niepoprawne hasła do SMTP).
Kiedyś obserwowałem takie ataki z ciekawością, prób były tysiące. Sprawę rozwiązało klasyczne: logowanie tylko kluczem oraz fail2ban. Plus niestandardowy port żeby logów nie zapychało zbytnio.
A no i jeszcze blokada logowania wprost na roota i tylko na zwyklego usera. Ktos da wiecej…?
Pewnie, że dam więcej. Dam ci priv escalation z tego Twojego usera. Blokuj sobie roota.
Blokowanie na roota to z czasów kiedy się używało telneta a packet sniffery łapały po kilka ramek, bo pamięci mało. Wtedy to miało sens, dziś nie bardzo.
moje wyniki, kto chce samemu sprawdzić, to polecam puścić:
LC_ALL=C zgrep sshd.*:\ Failed\ password\ for /var/log/auth.log*|awk ‘{print $9}’|sort|uniq -c|sort -rn|head -15|grep -v invalid
459737 root
72 postgres
43 mysql
39 jenkins
26 bin
23 backup
19 vnc
18 sshd
15 proxy
14 www-data
12 uucp
12 mail
12 lp
LC_ALL=C zgrep sshd.*:\ Failed\ password\ for\ invalid /var/log/auth.log*|awk ‘{print $11}’|sort|uniq -c|sort -rn|head -15
3377 admin
433 support
321 ubnt
287 usuario
246 user
229 pi
210 test
133 oracle
97 administrator
83 ftpuser
68 mother
62 nagios
61 git
51 ubuntu
51 guest
Na 3 miejscu ubnt? co to takiego?
3 ubnt 110
to “nie potrafie zainstalować debiana”
a tak serio ubiquiti
Są skrypty, które pozwalają logi fail2ban postować do AbuseIPDB.
link?
Fail2ban sam to umie, wystarczy poczytać dokumentację.
Polecam takie regułki, by odsiać wiele botów:
https://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html#comment-19302
U mnie jakoś tak:
Pacjent 1 (fail2ban)
114 admin
32 pi
13 support
12 ubnt
12 oracle
10 test
7 user
6 usuario
6 guest
5 nagios
Pacjent 2:
35456 admin
29422 test
18330 nagios
17590
14649 user
12259 ubnt
11950 oracle
10398 support
10137 pi
7384 git
Brane z lastb