19:37
9/4/2015

* Opis grupy atakującej SSH

Zorganizowana grupa hostów (wcześniej 103.41.124.0/23 a obecnie 43.255.190.0/23), skanuje klasy adresowe w poszukiwaniu portu SSH, a następnie odpala ataki słownikowe (tu słownik). Po odgadnięciu hasła, z innej podsieci następuje wjazd i pobranie DDoS rootkita z domen wskazujących na adres 23.234.60.140 (uprzednio) a obecnie 23.234.19.202. Szczegóły operacji i demontażu grupy tutaj.

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.

23 komentarzy

Dodaj komentarz
  1. prawda tez mi na klika weszlo propnuje na serverach iptables -A INPUT -s 43.255.190.0/23 -j DROP

  2. Fail2ban może być w tym przypadku bardzo przydatny.

  3. Wystarczy limit na połączenia w iptables i nawet nie trzeba Fail2bana.

  4. /etc/ssh/sshd_config
    PermitRootLogin no
    PasswordAuthentication no

    /etc/pf.conf
    table persist
    block in quick proto tcp from to any

    pass in on $ext_if proto tcp to any port ssh flags S/SA keep state \
    (max-src-conn 5, max-src-conn-rate 5/5, overload flush)

    I po problemie.

    • w pierwszym ‘block’ masz ‘quick’ więc już nie dojdzie do następnej reguły ‘pass’

  5. Jak w takich przypadkach sprawdza się obrona przy pomocy 2FA od google?
    Oczywiście nie ma co bagatelizować jakichkolwiek innych zabezpieczeń(jak chociażby zmiana portu, trudne hasło, ograniczenie logowania do konkretnych ip/sieci/lokalnie) tylko przez to, że zabezpieczyło się dostęp przez 2FA. Ale czy sama w sobie ta metoda jest skuteczna?

    • inny port, klucz zamiast hasła, whitelisting IP albo portknocking i po bólu.

  6. Dzięki za wykrzaczenie Chrome :P

    Biedny ten słownik, kilku “podstawowych” haseł brakuje.

  7. # gunzip -c /var/log/fail2ban.log.*.gz | egrep -c “43.255.190|103.41.124”
    782
    # cat /var/log/fail2ban.log /var/log/fail2ban.log.1 | egrep -c “43.255.190|103.41.124”
    172

    Jadą…

    • Ech, a ja właśnie zanotowałem 6000-czną próbę ataku na moje SSH :-) Logowanie kluczem i fail2ban załatwia sprawę

  8. @m4tek zamiast gunzip | egrep proponuje zcat :)

    • a ja proponuje wam zgrep :)

    • dzieki, przydatne w one-linerach

  9. btw. z takimi “atakami” u siebie radzę sobie tak:
    ip które próbuje się wbić na ssh z loginem innym niż dopisany w AllowUsers
    łapie się na jail z fail2ban po pierwszej próbie połączenia z bantime 2^10 :P
    do tego auth, tylko po kluczach. myślałem nad port-knock ale mało to wygodne :D
    jak by ktoś chciał. filtr do f2b ->
    [code]
    [INCLUDES]

    before = common.conf

    [Definition]
    _daemon = sshd
    failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from \s*$
    ignoreregex =
    [code]

    • Zastosuj takie regułki i daj znać:
      iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –name tcp22 –set
      iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –name tcp22 –update –seconds 8 –hitcount 2 -j DROP
      iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –name tcp22 –update –seconds 360 –hitcount 3 -j ACCEPT
      a ludzie wciąż używają armat na muchy.

  10. failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST&rt;\s*$

  11. Od kilku dni masowy SSH bruteforce idzie też z 218.65.30.107

    Sporo osób to zgłosiło:
    http://www.abuseipdb.com/report-history/218.65.30.107

  12. Takie ataki z przeróżnych adresów od dobrych kilku lat obserwuję. Żadna nowość.

  13. Potwierdzam, atakowali także mój serwer. Zainstalowałem fail2ban i z głowy

  14. Czy ten słownik zawiera hasła za pomocą których udało się włamać na serwer ssh (patrz trzecia kolumna)? Jeśli tak to jakim cudem hasło typu sXjdDH2ZIn zostało złamane?

  15. Od dłuższego czasu to obserwowałem.
    U mnie logowanie roota dla ssh jest wyłączone, do tego fail2ban na wszelki wypadek.
    Zbieram się od dłuższego czasu, żeby wystawić pustą wirtualkę z jakimś lame rootem. bo jestem ciekawy co będzie, jak już się wbiją. Może niebezpiecznik opisałby co czeka zbotnetowanego w ten sposób hosta?

    • U mnie doszło do infekcji (słabe hasło roota). Zainfekowana wirtualka miała automatycznie uruchamiany program z losową nazwą startowany z init.d oraz ustawiony w cron.hourly skrypt gcc.sh podmieniajacy /lib/libudev.so.6. Po killowaniu programu uruchamiał się kolejny z inną nazwą i tak w kółko. Co więcej prawdopodobnie trwał atak ddos, bo router netiaspot stawał się nieosiągalny w LAN. Żeby to usunąć wyłączyłem wszystkie skrypty startowe i bez killowania rootkita wyłączyłem hosta. Ale pewności nie mam więc i tak reinstalka.

  16. doorman załatwia sprawę

Twój komentarz

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