„MOŻLIWA PRÓBA ZAŁAMANIA SIĘ!” W / var / log / secure

96

Mam urządzenie CentOS 5.x działające na platformie VPS. Mój host VPS źle zinterpretował moje zapytanie dotyczące pomocy technicznej dotyczące łączności i skutecznie opróżnił niektóre reguły iptables. Spowodowało to nasłuchiwanie ssh na standardowym porcie i potwierdzenie testów łączności portów. Denerwujący.

Dobra wiadomość jest taka, że potrzebuję kluczy autoryzowanych przez SSH. O ile mi wiadomo, nie sądzę, aby miało miejsce jakiekolwiek udane naruszenie. Nadal jestem bardzo zaniepokojony tym, co widzę w / var / log / secure:

Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

Co dokładnie oznacza „MOŻLIWA PODEJŚCIE DO PRZERWANIA”? Że się udało? A może nie podoba się adres IP, z którego pochodzi żądanie?

— Mike B.
źródło

78

Niestety jest to obecnie bardzo częste zjawisko. Jest to automatyczny atak na SSH, który używa „wspólnych” nazw użytkowników, aby spróbować włamać się do twojego systemu. Wiadomość oznacza dokładnie to, co mówi, nie oznacza, że zostałeś zhakowany, tylko że ktoś próbował.

— Iain
źródło

Dzięki Lain. To sprawia, że czuję się lepiej. Cieszę się, że potrzebuję autoryzowanych kluczy do ssh. =)

— Mike B

28

„Odwrotne mapowanie sprawdzające getaddrinfo dla” dotyczy więcej spreparowanych źródłowych adresów IP / hostów. Ten sam spreparowany ruch próbuje wypróbować złe nazwy użytkowników, ale złe nazwy użytkowników nie generują komunikatu „MOŻLIWA PODEJMOWANIE PROBLEMU”.

— trucizna

11

@MikeyB: Być może warto przyjrzeć się dodaniu do systemu fail2ban . Można to skonfigurować do automatycznego blokowania adresów IP tych osób atakujących.

— user9517

9

Zauważ, że „odwrotne mapowanie nie powiodło się” może po prostu oznaczać, że dostawca usług internetowych użytkownika nie skonfigurował poprawnie odwrotnego DNS, co jest dość powszechne. Zobacz odpowiedź @ Gaia.

— Wilfred Hughes,

1

Jest to niedokładne, oznacza to po prostu, że odwrotny DNS nie pasuje do nazwy hosta wysłanej przez klienta w celu identyfikacji. Prawdopodobnie jest oflagowany, ponieważ może to być przerwa w usłudze dla osób używających .rhostslub .shostsuwierzytelniających (nigdy tego nie widziałem). Skanowanie się dzieje, ale nie o to chodzi w tym komunikacie (chociaż każde połączenie może go wyzwolić) (W przypadku skanów lepiej szukać komunikatów o nieudanym uwierzytelnieniu / nieznanym użytkowniku)

— Gert van den Berg

52

Część „MOŻLIWE PODEJŚCIE DO PRZERWANIA” jest szczególnie związana z częścią „sprawdzanie odwrotnego odwzorowania getaddrinfo nie powiodło się”. Oznacza to, że osoba, która się łączyła, nie skonfigurowała poprawnie przekazywania i odwrotnego DNS. Jest to dość powszechne, szczególnie w przypadku połączeń ISP, skąd prawdopodobnie pochodzi „atak”.

Osoba niepowiązana z komunikatem „MOŻLIWE PODEJŚCIE DO PRZERWANIA” faktycznie próbuje włamać się, używając wspólnych nazw użytkowników i haseł. Nie używaj prostych haseł do SSH; w rzeczywistości najlepszym pomysłem jest całkowite wyłączenie haseł i używanie tylko kluczy SSH.

— Chris S.
źródło

1

Jeśli jest generowany przez (prawidłowe) połączenie za pośrednictwem usługodawcy internetowego, możesz dodać wpis do pliku / etc / hosts, aby pozbyć się tego błędu odwrotnego mapowania. Oczywiście zrobiłbyś to tylko wtedy, gdybyś wiedział, że błąd jest łagodny i chcesz wyczyścić swoje dzienniki.

— artfulrobot,

32

„Co dokładnie oznacza„ MOŻLIWA PODEJŚCIE DO PRZERWANIA ”?

Oznacza to, że właściciel netblock nie zaktualizował rekordu PTR dla statycznego adresu IP w swoim zakresie, i powiedział, że rekord PTR jest nieaktualny, LUB dostawca usług internetowych nie skonfiguruje odpowiednich rekordów zwrotnych dla swoich klientów dynamicznego adresu IP. Jest to bardzo powszechne, nawet w przypadku dużych dostawców usług internetowych.

W końcu dostajesz msg do twojego dziennika, ponieważ ktoś pochodzący z adresu IP z niewłaściwymi rekordami PTR (z jednego z powyższych powodów) próbuje użyć wspólnych nazw użytkowników, aby wypróbować SSH na twoim serwerze (prawdopodobnie atak bruteforce, a może uczciwy błąd) ).

Aby wyłączyć te alerty, masz dwie możliwości:

1) Jeśli masz statyczny adres IP , dodaj odwrotne mapowanie do pliku / etc / hosts (zobacz więcej informacji tutaj ):

10.10.10.10 server.remotehost.com

2) Jeśli masz dynamiczny adres IP i naprawdę chcesz, aby te alerty zniknęły, skomentuj „GSSAPIAuthentication yes” w pliku / etc / ssh / sshd_config.

— Gaia
źródło

2

komentowanie GSSAPIAuthenticationnie pomaga w moim przypadku (

— SET

UseDNS noto prawdopodobnie lepsze ustawienie, aby się go pozbyć (i powolnych logowań, gdy serwer ma problemy z DNS ...)

— Gert van den Berg

15

Możesz ułatwić czytanie i sprawdzanie dzienników poprzez wyłączenie wyszukiwania wstecznego w sshd_config (UseDNS no). Zapobiegnie to rejestrowaniu przez sshd linii „szumu” zawierających „MOŻLIWĄ PRÓBĘ PRZERWANIA”, pozwalając ci skoncentrować się na nieco bardziej interesujących liniach zawierających „Nieprawidłowy użytkownik USER z adresu IPADDRESS”.

— TimT
źródło

4

Jakie są wady wyłączania wyszukiwania wstecznego sshd na serwerze podłączonym do publicznego Internetu? Czy pozostawienie tej opcji jest w ogóle pozytywne?

— Eddie,

2

@Eddie Nie sądzę, że wyszukiwania DNS wykonywane przez sshd służą jakiemukolwiek użytecznemu celowi. Istnieją dwa dobre powody, aby wyłączyć wyszukiwanie DNS. Wyszukiwanie DNS może spowolnić logowanie, jeśli upłynie limit czasu wyszukiwania. A komunikaty „MOŻLIWE PODEJŚCIE DO PRZERWANIA” w dzienniku wprowadzają w błąd. Tak naprawdę oznacza to, że klient źle skonfigurował DNS.

— kasperd

1

Nie zgadzam się z @OlafM - „UseDNS no” mówi sshd, aby nie przeprowadzał sprawdzania odwrotnego odwzorowania i dlatego nie doda żadnych wierszy zawierających „MOŻLIWĄ PRÓBĘ PRZERWANIA” do dzienników systemowych. Jako efekt uboczny może także przyspieszyć próby nawiązania połączenia z hosta, niż nieprawidłowo skonfigurowany odwrotny DNS.

— TimT

1

Tak @OlafM Zrobiłem to około 4-5 lat temu na Linuksie. To znacznie skróciło moje dzienniki i przestało logcheckmnie denerwować bezwartościowymi raportami e-mail.

— TimT

1

Głównym zastosowaniem UseDNSjest (zły pomysł) .rhostsi .shostsuwierzytelnianie ( HostbasedAuthentication). (Oraz Fromopcja dopasowania w konfiguracji SSHD i uprawnionych kluczach) (Istnieje jednak osobne ustawienie, HostbasedUsesNameFromPacketOnlyktóre może być potrzebne do przełączania wyszukiwania wstecznego dla uwierzytelniania opartego na hostach, gorszy pomysł niż przy użyciu uwierzytelniania opartego na hostach ...)

— Gert van den Berg

5

Nie jest konieczne pomyślne logowanie, ale to, co mówi „możliwe” i „próba”.

Jakiś zły chłopiec lub skrypty dzieciak, wysyła ci spreparowany ruch z fałszywym adresem IP pochodzenia.

Możesz dodać ograniczenia adresu IP pochodzenia do kluczy SSH i spróbować czegoś takiego jak fail2ban.

— trucizna
źródło

2

Dzięki. Mam ustawione iptables, aby zezwalać na łączność ssh tylko z wybranych źródeł. Mam również zainstalowany i uruchomiony fail2ban.

— Mike B

„MOŻLIWA PRÓBA ZAŁAMANIA SIĘ!” W / var / log / secure - co to znaczy?