22:42
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
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.

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

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

    • 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 :)

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

  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.

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

  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?

    • Fail2ban sam to umie, wystarczy poczytać dokumentację.

  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

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

Odpowiadasz na komentarz K

Kliknij tu, aby anulować

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

RSS dla komentarzy: