Tak, wygląda na to, że doświadczasz ataku brutalnej siły. Atakujący znajduje się na adresie prywatnym klasy B, więc prawdopodobnie jest to osoba mająca dostęp do sieci organizacji, która przeprowadza atak. Z nazw użytkowników wygląda na to, że są one uruchomione przez słownik typowych nazw użytkowników.

Spójrz na „Jak zatrzymać / zapobiegać brutalności SSH” (Błąd serwera) i „Zapobieganie brutalnym atakom SSH” (Rimu Hosting) o tym, jak podjąć środki w celu ograniczenia części ryzyka związanego z brutalnymi atakami SSH.

Tak, wygląda to dokładnie jak atak brutalnej siły i po wygooglowaniu admins phoenix piglet rainbow wygląda na to, że jest to lista słów, której używa atakujący: https://github.com / hydrogen18 / kojoney / blob / master / fake_users
Sprawdź linię 116 i dalej. Lista słów jest używana dokładnie w tej samej kolejności.
Wygląda na to, że jest to ogólna lista słów, ponieważ występuje również w innych witrynach. na przykład http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users

@TheJulyPlot dostarczył dobrych informacji o tym, co zrobić, aby złagodzić ten atak.

Dodano krótką notatkę na temat fail2ban , o czym wspominało wiele osób: front-end to korporacyjna zapora ogniowa, zaplecze widzi tylko przekierowanie / proxy / adres wewnętrzny z firewalla.

Więc nie, 172.25.1.1 nie jest zhakowaną maszyną wewnętrzną (i zarówno komentarz w odpowiedzi, jak i inna odpowiedź tutaj stwierdzająca, że ​​jest to maszyna wewnętrzna mylą się podczas komentowania tego). Jest to jeden z wewnętrznych adresów IP firewalla.

Fail2ban w zapleczu blokowałby tylko możliwość używania SSH do rozciągania na raz, ponieważ widzi tylko nieudane próby z 172.25.1.1. Więc proszę, przeczytaj moją odpowiedź.

Nie ma wątpliwości, jak wspominają inne posty, jest boleśnie oczywiste, że jesteś pod brutalnym atakiem.

Jednak to wcale nie znaczy, że jesteś w jakikolwiek sposób narażony na szwank z dzienników, które nam pokazałeś. Niestety, obecnie ataki ssh brute force są zbyt powszechne. W większości przypadków są one naprawdę zautomatyzowane i niekoniecznie jesteś celem.

Jako anegdotyczne ostrzeżenie kilka lat temu pierwszego dnia, w którym skonfigurowałem nowe serwery u dostawcy usług internetowych, ssh jeden otwarty do Internetu w ciągu jednej nocy otrzymało ponad 200 tysięcy sond skanujących ssh.

Jeśli chodzi o „wewnętrzny adres IP”, albo używasz SNAT, albo w najlepszym przypadku przekierowania proxy 22 / TCP, a źródłowe adresy internetowe nie pokazuj (co nie jest najlepszą praktyką) lub w najgorszym przypadku twój router / modem kablowy jest zagrożony.

Jeśli naprawdę masz konfigurację SNAT / proxy SSH, radzę ci to przemyśleć . Chcesz logów prawdziwych adresów IP, a nie twojej sieci.

Jeśli chodzi o środki, polecam kilka:

1. Nie zezwalaj na hasła w SSH; tylko loginy przy użyciu certyfikatów RSA;
2. Nie otwieraj ssh na zewnątrz; ogranicz je do swojej sieci wewnętrznej;
3. Aby uzyskać dostęp z zewnątrz, dostęp przez VPN; nie ujawniaj SSH w całym Internecie;
4. ograniczające prędkość sieci SYN z zewnątrz.

Jeśli absolutnie nalegasz, aby nadal mieć otwarty Internet SSH na zewnątrz, pamiętaj, że zmiana domyślnego portu SSH daje tylko fałszywe poczucie bezpieczeństwa, a tymczasowe blokowanie adresów IP spowalnia atak tylko tak często, o czym mówimy skoordynowane farmy maszyn zombie.

Możesz rzucić okiem na fail2ban , jeśli zmienisz konfigurację, aby otrzymywać bezpośrednio publiczne adresy IP łączące się z tobą; jednak weź pod uwagę, że jeśli rzeczywiście jakikolwiek zewnętrzny adres IP nadejdzie z adresem IP twojej bramy, skutecznie blokujesz cały zewnętrzny dostęp SSH przy jego użyciu.

Istnieją również inne zastrzeżenia; proszę zauważyć, że obecnie zombie / złośliwe oprogramowanie biorą pod uwagę fail2ban i powracają po domyślnym czasie lub na zmianę z różnymi adresami IP. (Widziałem, jak to się dzieje). Nawet jeśli używasz obowiązkowego uwierzytelniania za pomocą certyfikatu RSA, ataki na hasło będą nadal rejestrowane i spowodują spalenie cykli we / wy, miejsca na dysku i procesora.

Jeśli chodzi o VPN, nie potrzebujesz dedykowanego sprzętu; konfiguracja VPN na serwerze Linux lub FreeBSD jest trywialna.

Jeśli nie czujesz się komfortowo konfigurując ją od zera, polecam maszynę wirtualną z pfSense. dla FreeBSD ; strongSwan do konfiguracji VPN na serwerze Linux.

Jeśli twój serwer frontonu to Linux, inną alternatywą jest pukanie portów. Jednak ze względu na jego nieodłączne działanie polecam go tylko do zastosowań domowych. Jak słusznie wskazał @GroundZero, „pukanie do portów jest zabezpieczeniem przez zaciemnienie, a osoba atakująca może aktywnie monitorować ruch sieciowy w celu wykrycia sekwencji pukania”.

Jak to zrobić Użyj funkcji Port Knocking, aby ukryć demona SSH przed atakującymi w systemie Ubuntu

Jako dodatkowy środek możesz również ograniczyć szybkość za pomocą reguł SYN firewalla / iptables w porcie 22. W ten sposób nie będziesz ograniczać swoich legalnych połączeń i albo iptables w Linuksie, albo większość komercyjnych zapór na to pozwala konfiguracja. Widziałem paskudne sztuczki, gdy boty atakowały niektóre demony tak szybko, jak to możliwe, zanim zaczną obowiązywać zasady bezpieczeństwa. Jednak wierzę, że faktycznie ssh ma wbudowaną ochronę przed tym.

Odpowiadając na temat szalejącego skanowania, tak naprawdę. Masz wielu złych aktorów, sieci zombie i złośliwe oprogramowanie, które stale skanują przestrzeń adresową IP, aby znaleźć serwery z zainfekowanymi wersjami sshd, podatnymi / starymi wersjami sshd, serwerami z domyślnymi / złymi hasłami / znanymi backdoorami i po prostu serwery z openssh do zdobycia przyczółek w nieuprzywilejowanym użytkowniku za pomocą brutalnej siły lub podwójnych ataków poprzez phishing.

Po trzech udanych atakach phishingowych (w osobnych zdarzeniach) na moim hoście bastionu w mojej obecnej pracy, zdecydowałem się zrobić podwójna konfiguracja ssh, w której wszyscy użytkownicy są proszeni o certyfikat RSA w sshd_config , a tylko sieć wewnętrzna umożliwia uwierzytelnianie hasłem, dodając na końcu pliku konfiguracyjnego jako takie:

  # konfiguracja sshd zezwalająca tylko na certyfikaty RSAMatch Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24PasswordAuthentication tak  

Kolejna anegdota przerażająca opowieść, zanim zmieniłem na obowiązkowe certyfikaty RSA , jeden z ataków phishingowych miał miejsce w t Dokładnie w tygodniu były dwie aktualizacje jądra pod kątem luk, które umożliwiły eskalację uprawnień do roota, a gdybym nie zaktualizował na miejscu, zostałbym przejęty przez roota. (i jeśli moja pamięć mnie nie zawodzi, to było około 4 lipca ... hakerzy uwielbiają zapisywać te paskudne ataki na święta)

Jeśli chodzi o wykresy rzeczywistych ataków na żywo w czasie rzeczywistym, spojrzenie na:

• Interfejs graficzny projektu nordyckiego. To bardzo pouczające.
• Mapa ataków DDoS.
• Bezpłatny widok centralnej sieci monitorowania bezpieczeństwa firmy Checkpoint, w której agenci są ich klientami.

Aby zakończyć odpowiedź:

Nie, prawdopodobnie nie zostałeś w żaden sposób zagrożony.

Tak, musisz podjąć kroki w celu zwiększenia poziomu bezpieczeństwa. Radziłbym tunel / klient VPN z zewnątrz do firmowego serwera VPN. To właśnie robię.

Mam również ostatnią i ważną radę: aby upewnić się, że zwykłe konto nie jest zagrożone, sprawdź swój /var/log/auth.log dzienniki uwierzytelniania dla pomyślnego uwierzytelnienia. Istnieją sposoby na zalogowanie się do openssh przy użyciu dowolnego konta bez rejestracji w / var / log / wtmp iw konsekwencji nie pojawienia się w poleceniu last .

Jest rzeczą oczywistą, że jeśli zwykłe konto zostanie przejęte na starym komputerze bez aktualizacji, wszystkie zakłady są wyłączone. A w niefortunnym przypadku eskalacji uprawnień do roota, nawet dzienniki mogą zostać naruszone.

Tak, jesteś brutalnie zmuszany. Ale myślę, że nie powinieneś się martwić o jakąkolwiek brutalność, którą wykryjesz, pochodzącą z Internetu. Powinieneś jednak martwić się atakami siłowymi pochodzącymi z Twojej własnej sieci.

Bycie brutalnym jest bardzo powszechne i dopóki nie używasz haseł do SSH (lub dobrych haseł) , atak w ogóle się nie powiedzie (szczególnie w przypadku jedno zgadywanie co 3-4 sekundy).

Chociaż adres IP (172.25.1.1) znajduje się w tej samej sieci co Ty. To jest prawdziwy problem i powinieneś sprawdzić, czy ta maszyna nie została przejęta tak szybko, jak to możliwe .

Wygląda na to, że przeżywasz atak. SSH robi to, co powinno. Jednak poniżej znajdziesz kilka kroków, które powinieneś podjąć jak najszybciej, aby zapewnić dalsze przetrwanie.

Ponadto, niestety, włamano się na system wewnątrz sieci. W dzisiejszych czasach zbyt powszechne. Powinieneś ustalić naturę tego pozornie wewnętrznego ataku, ale nie zakładaj, że ten system jest zagrożony po prostu na podstawie tego pliku dziennika . Każdy, kto korzysta z dysku SSHD do wyświetlania w sieci, widział to już od lat. Napraw instalację dysku SSHD na tym hoście, a następnie zbadaj system pod adresem 172.25.1.1.

Postępuj zgodnie z najlepszymi praktykami dotyczącymi SSHD, takimi jak te ...

Wyłącz uwierzytelnianie hasła na korzyść uwierzytelniania opartego na kluczach:

  # grep PasswordAuth sshd_config | grep noPasswordAuthentication no  

Jak wspomniano, wyłącz logowanie roota:

  PermitRootLogin no  

Dodaj dozwolonych użytkowników do sshd_config:

  AllowUsers myusername the_other_sysop_guy  

Jeśli zrobisz to ostatnie, komunikat dziennika zmieni się od „nieprawidłowego użytkownika” do „nielegalnego użytkownika”.

W zależności od sytuacji biznesowej możesz również pomyśleć o zaporze ogniowej portu SSHD (zezwalaj na SSH tylko z autoryzowanych adresów IP) lub zmianie go na używanie innego portu (co jest naprawdę zabezpieczeniem przez zaciemnienie, ale większość ataków tego rodzaju jest w rzeczywistości skryptowana). Niestety, fakt, że osoba atakująca wydaje się znajdować się w Twojej sieci LAN, może spowodować, że nie będą one oferować tak dużej pomocy, jak w przeciwnym razie.

Nawiasem mówiąc, fakt, że urządzenie jest w wersji 1.1, sprawia, że ​​zastanawiam się, czy ' dostałeś się do routera? ;-)

Standardowy wygląd dzienników wydaje się być powszechnym atakiem siłowym, ponieważ nazwy zapisane w dziennikach pochodzą z używanego standardowego słownika. Nawet popularne listy słów traktują je jako główne docelowe nazwy użytkowników. Ponadto wstrzyknięcie pochodzi z adresu IP klasy prywatnej B. Nie martw się jednak, o ile wymuszone hasła są wystarczająco silne i masz równowagę obciążenia, aby sobie z tym poradzić, nie będzie dla ciebie problemem. Poszukaj środków, aby to zabezpieczyć w środkach SSH Brute Force Protection w SSH.

Ponieważ wszystkie logowania SSH do twojego serwera są przekierowywane przez ten sam lokalny adres IP, radziłbym ostrożnie używać fail2ban , jeśli zdecydujesz się go użyć. Zainstalowanie fail2ban na tym samym serwerze co sshd spowoduje natychmiastowe zablokowanie adresu IP 172.25.1.1. Potem nikt nie będzie mógł zalogować się przez SSH do twojego serwera.

Jeśli możesz zainstalować fail2ban na serwerze, który przekierowuje ruch SSH, zrób to. Używam fail2ban na moim publicznym serwerze SSH i świetnie sobie radzi, ograniczając atakującego do 3 prób w 10 minut. Większość skryptów do „łamania” skryptów używanych przez dzieciaki po prostu przekroczy limit czasu po tych 3 próbach i nie będzie mi przeszkadzać przez wiele dni.

Możesz także dość łatwo spowolnić zgadywanie hasła atakującego.

W pliku /etc/pam.d/sshd możesz dodać taką linię:

  auth opcjonalne pam_faildelay.so delay = 7000000  

Przy każdej nieudanej próbie logowania sshd moduł PAM będzie czekał 7 sekund. Możesz chcieć zwiększyć lub zmniejszyć opóźnienie, ponieważ jeśli pogłębisz swoje własne hasło, odczekasz 7 sekund, aby otrzymać kolejny monit. Zaryzykowałbym przypuszczenie, że większość programów do zgadywania haseł SSH jest tak nieskomplikowana, że ​​nie ma limitu czasu związanego z oczekiwaniem na nowy monit, ale możliwe jest, że naprawdę duże opóźnienie spowodowałoby po prostu przekroczenie limitu czasu przez lepsze programy do zgadywania w pewnym momencie. / p>