22:42
18/6/2017

Advertisement

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

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.


26 komentarzy

Dodaj komentarz
  1. 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.

  2. Dobrze jest też zmienić port serwera SSH na jakiś wysoki, niestandardowy. To skutecznie odsiewa 90% botów.

  3. A może dodamy do tego port-knocking? ;)

  4. … 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).

  5. 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.

  6. 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.

  7. 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

  8. Na 3 miejscu ubnt? co to takiego?

    3 ubnt 110

    • to “nie potrafie zainstalować debiana”

    • a tak serio ubiquiti

  9. Są skrypty, które pozwalają logi fail2ban postować do AbuseIPDB.

    • link?

  10. Polecam takie regułki, by odsiać wiele botów:
    https://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html#comment-19302

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: