Czy normalne jest wykonywanie setek prób włamań dziennie?

196

Właśnie sprawdziłem serwer /var/log/auth.logi stwierdziłem, że codziennie otrzymuję ponad 500 nieudanych powiadomień o haśle / próbie włamania! Moja witryna jest niewielka, a jej adres URL jest niejasny. Czy to normalne? Czy powinienem podjąć jakieś środki?

Kyle
źródło
2
Dopóki nie zablokowaliśmy wszystkich niepotrzebnych portów zewnętrznych, pamiętam nie tylko, że dostaliśmy wiele prób włamań, ale pewnego dnia było tak źle, że byliśmy włamywani z dwóch różnych krajów - w tym samym czasie! Tak więc 100s prób włamania jest całkowicie normalne.
Django Reinhardt
91
Mamy serwery, które doświadczają nowej „sekwencji” ataku co 16 sekund. Pojedyncza sekwencja to zazwyczaj partia około 100 prób w różnych portach. Tylko dla kopnięć pewnego dnia włączyłem niepoprawny serwer poza naszą zaporą; to trwa mniej niż 10 minut od momentu włączenia, aby uzyskać pwnd. Chodzi o to, że internet to prawdziwa dżungla; staraj się nie zostać zjedzonym.
NotMe
2
Widzę, że zamieściłem moje pytanie na niewłaściwej stronie: superuser.com/questions/200896/…
Justin C
6
chociaż zgadzam się z innymi, jest to normalne w przypadku typowych wymaganych portów (80, 443). Praktycznie wyeliminowałem te próby z moim portem SSH, po prostu zmieniając domyślny port z 22 na coś niejasnego, na przykład 6022. Samo wykonanie tej czynności prawie wyeliminowało 99% tego typu ataków.
Kilo
2
Jeśli zamierzasz zmienić swój port SSH, istnieją powody związane z bezpieczeństwem, aby utrzymać go poniżej portu 1024 (tylko root może otwierać porty <1024, więc chroni cię przed przejęciem SSH przez innych użytkowników).
Brendan Long

Odpowiedzi:

207

Niestety w dzisiejszym Internecie jest to całkiem normalne. Istnieją hordy botnetów próbujących zalogować się do każdego serwera, który znajdą w całych sieciach IP. Zazwyczaj używają prostych ataków słownikowych na dobrze znane konta (takie jak konta root lub niektóre aplikacje).

Celów ataku nie można znaleźć za pomocą wpisów Google ani DNS, ale osoby atakujące po prostu próbują każdego adresu IP w określonej podsieci (np. Znanych firm hostingowych serwerów głównych). Więc nie ma znaczenia, że ​​twój adres URL (stąd wpis DNS) jest raczej niejasny.

Dlatego tak ważne jest:

  • nie zezwalaj na rootowanie w SSH ( howto )
  • wszędzie używaj silnych haseł (także w aplikacjach internetowych)
  • w przypadku SSH użyj uwierzytelnienia kluczem publicznym, jeśli to możliwe, i całkowicie wyłącz uwierzytelnianie hasła ( howto )

Dodatkowo możesz zainstalować fail2ban, który skanuje authloga, a jeśli wykryje pewną liczbę nieudanych prób logowania z adresu IP, będzie kontynuował dodawanie tego adresu IP do /etc/hosts.denylub iptables / netfilter w celu zablokowania atakującego na kilka minut.

Oprócz ataków SSH często zdarza się również, że skanujesz swój serwer sieciowy w poszukiwaniu wrażliwych aplikacji internetowych (niektóre aplikacje blogowe, CMS, phpmyadmin itp.). Upewnij się więc, że są aktualne i bezpiecznie skonfigurowane!

Holger Just
źródło
21
Aplikacje takie jak fail2ban mogą bardzo pomóc „tymczasowo” powstrzymać te boty przed uderzeniem twojego serwera w głupie poranki :-) Mam skonfigurowane, by blokować 3 nieprawidłowe próby na 24 godziny.
emtunc,
46
I przenieś port ssh z 22 do 222. To działa całkiem dobrze.
Tom O'Connor,
40
+1, tylko uwierzytelnianie za pomocą klucza publicznego :)
0xC0000022L
3
@STATUS_ACCESS_DENIED: działania podejmowane przez fail2ban są tylko listami poleceń powłoki do uruchomienia. Jest więc naprawdę elastyczny i łatwy do poprawnego działania z dowolną niestandardową konfiguracją. Najlepszym odniesieniem jest pobranie go i obejrzenie action.d/iptables.conf.
mattdm
4
Blokowanie takich atakujących to strata czasu. Jeśli wyłączysz logowanie roota, istnieje duża szansa, że ​​nikt nawet nie zgadnie twojej poprawnej nazwy logowania, a tym bardziej hasła. Sam SSH już teraz ogranicza żądania hasła, więc nawet jeśli znają twoją nazwę użytkownika (losowe boty nie), jeśli masz przyzwoite hasło, nigdy go nie zgadną.
Brendan Long
58

Kilka 100 jest w porządku ... W zeszłym miesiącu odkryłem, że jeden z moich serwerów miał 40 000 nieudanych prób. Przeszedłem przez kłopot z ich wykreśleniem: Mapa

Gdy zmieniłem port ssh i wdrożyłem Port Knocking, liczba spadła do 0 :-)

Bart De Vos
źródło
2
Ładna mapa. Chciałbym wiedzieć, jak to zrobić!
jftuga
9
@ jftuga Najpierw uzyskałem wszystkie adresy IP z dzienników. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(usuń | uniq na końcu, jeśli chcesz zezwolić na duplikaty). Następnie możesz umieścić je w pliku CSV i przesłać na stronę zeemaps.com. Widziałem lepsze mapy niż moje, w których użyłyby licznika do pokolorowania mapy (kolor zielony do czerwonego dla liczby prób w hrabstwie), ale nie pomyślałem, że jedna z nich
Bart De Vos
3
Co rozumiesz przez „wdrożony Port Knocking”? Czy istnieje aplikacja, którą mogę zainstalować za pomocą apt-get, aby to zrobić? Liczba spadająca do zera brzmi nieźle
18
Bezpieczeństwo wynikające z niejasności staje się złe. Jest w porządku, o ile stanowi część ogólnej strategii, a nie całej strategii. W końcu czym innym jest hasło oprócz niejasnego ciągu?
Joel Coel,
5
@Jel Coel, jest to tajny ciąg, w przeciwieństwie do większości zabezpieczeń powodowanych przez problemy związane z niejasnością - niejasny, ale niekoniecznie tajny proces.
tobyodavies,
29

Ja na przykład używam „tarpit” oprócz zezwalania tylko na uwierzytelnianie za pomocą klucza publicznego i nie zezwalanie na rootowanie.

W netfilteristnieje recentmoduł, który można używać z ( INPUTłańcuch):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

To oznacza, że ​​każda próba połączenia z portem 22 jest wymieniona przez recentmoduł z adresem IP i innymi rzeczami pod nazwą „tarpit” (jeśli jesteś ciekawy, spójrz /proc/net/xt_recent/tarpit). Oczywiście możesz używać innych nazw.

Aby wyświetlić lub usunąć adresy IP, użyj:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Ta szybkość ogranicza próby do 5 w 300 sekund. Należy pamiętać, że użytkownicy z istniejącym połączeniem nie przejmują się tym limitem, ponieważ mają już ustanowione połączenie i mogą tworzyć więcej (nawet powyżej limitu prędkości).

Dostosuj reguły do ​​swoich upodobań, ale upewnij się, że zostaną dodane w tej kolejności (tzn. Dodając, użyj ich w tej kolejności, wstawiając następnie w odwrotnej kolejności).

To ogromnie zmniejsza hałas. Zapewnia również faktyczne bezpieczeństwo (przed brutalnym wymuszaniem) w przeciwieństwie do postrzeganego bezpieczeństwa zmiany portu. Jednak nadal zalecam zmianę portu, jeśli jest to wykonalne w twoim środowisku. To również znacznie obniży poziom hałasu ...

Nadal możesz połączyć to z fail2ban, chociaż działałem dobrze bez niego i tylko z powyższymi zasadami.

EDYTOWAĆ:

Możliwe jest zablokowanie się w ten sposób, dzięki czemu możesz dodać coś takiego, co pozwoli ci usunąć ban poprzez pukanie do określonego portu:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove
0xC0000022L
źródło
2
Używam tego i czasami udaje mi się zablokować, więc lubię ustawić inny port, abyś mógł „zapukać”, aby usunąć swój ban.
benlumley,
@benlumley: dobry punkt. Pukanie portów może być podobnie przydatne do zmiany domyślnego portu - lub nawet obu w kombinacji ...
0xC0000022L
@benlumley: zobaczył twój komentarz (teraz usunięty przez Sama). Absolutnie nie mam nic przeciwko, jeśli odpowiedź zostanie edytowana / poprawiona;)
0xC0000022L,
15

Możesz zaimplementować fail2ban lub podobne metody, takie jak blokowanie SSH do twojego adresu IP. Niestety boty cały czas próbują brutalnie wymuszać dostęp, więc jest to całkiem normalne, musisz upewnić się, że masz dobre hasło.

Jakub
źródło
3
Jeśli używasz SSH, rozważ uwierzytelnianie za pomocą klucza publicznego. Jest to nieco bezpieczniejsze niż uwierzytelnianie hasłem.
Piskvor,
12

Tak . W dzisiejszych czasach jest to całkiem normalne.

Jeśli to możliwe, używaj tylko uwierzytelniania klucza publicznego do celów administracyjnych. Wygeneruj klucz prywatny na swojej stacji roboczej:

$ ssh-keygen -t dsa

Skopiuj zawartość ~ / .ssh / id_dsa.pub do swoich serwerów ~ / .ssh / Author_keys (i /root/.ssh/authorized_keys, jeśli potrzebujesz bezpośredniego logowania roota).

Skonfiguruj swoje serwery / etc / ssh / sshd_config, aby akceptować tylko uwierzytelnianie za pomocą klucza publicznego:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Jeśli masz zbyt wiele serwerów, możesz użyć Puppet do uruchamiania na nich kluczy publicznych i konfiguracji.

Zajrzyj do Denyhosts i fail2ban, aby zablokować powtarzające się próby logowania SSH i zobacz Snort, jeśli potrzebujesz pełnego IDS / IPS.

jkj
źródło
2
Nie polecam używania uwierzytelniania klucza publicznego w SSH w celu uzyskania dostępu do powłoki na serwerze. Jeśli twoja stacja robocza jest zagrożona lub, co gorsza, skradziona, to ktoś ma teraz otwarty dostęp do twoich serwerów bez potrzeby podawania hasła. Uwierzytelnianie za pomocą klucza publicznego jest bardziej przydatne w sytuacjach, gdy potrzebujesz czegoś takiego jak skrypt lub program, aby mieć dostęp do SSH do innego systemu bez potrzeby podawania hasła, więc nie musisz osadzać haseł tekstowych w skrypcie / programie.
Zarejestrowany użytkownik
5
@Deleted Account: Możesz ustawić hasło dla klucza prywatnego SSH.
Phil Cohen,
2
Komentarz „Zarejestrowanego użytkownika” jest mylący. Wyjaśnij: zawsze ustaw dobre hasło na klucz prywatny i nie przechowuj klucza prywatnego na żadnym serwerze. Zachowaj klucz prywatny na własnym stanowisku roboczym. Po dodaniu klucza do programu ssh-agent i wpisaniu hasła można zalogować się do każdego systemu, w którym zainstalowany jest klucz publiczny, bez konieczności ponownego wprowadzania hasła. Włącz przekazywanie agentów w kliencie ssh, aby móc logować się z serwera na serwer. Kradzież klucza prywatnego jest zła, ale z przyzwoitym hasłem nie jest tak zła, jak skradzione hasło.
Martijn Heemels
Racja, nawet nie myśl o przechowywaniu kluczy prywatnych administratora niezaszyfrowanych.
yrk
8

użyj http://denyhosts.sourceforge.net/

i tak, należy użyć uwierzytelniania z kluczem publicznym i wyłączyć uwierzytelnianie hasła.

numer 5
źródło
Wyłączenie uwierzytelniania hasła nie zawsze jest realnym rozwiązaniem.
Publiccert,
6

Próby są zmechanizowane, więc liczby wydają się OK (tak, są wysokie w porównaniu do niektórych witryn i niskie w porównaniu do innych). Powinieneś podjąć kroki, które zwykle musisz: Uważasz swoje witryny za cele ataku każdego dnia, nawet jeśli nie wykryjesz ataku; nie wykrycie ataku, nie oznacza, że ​​nie istnieje .

adamo
źródło
6

Powiedziałbym, że zdobycie tylko 500 jest trochę niskie.

U poprzedniego pracodawcy jeden z badaczy bezpieczeństwa komputerowego nazwał ciągły strumień prób włamania „internetowym odpowiednikiem szumu kosmicznego ”. Opisał to jako normalny, ciągły przepływ złośliwego ruchu, który szukał systemów w Internecie i automatycznie wykorzystuje skrypty do próby przejęcia systemu. Bot-sieci i inne złośliwe systemy nieustannie skanowałyby i ponownie skanowały Internet w poszukiwaniu wrażliwych systemów, takich jak SETI.

James Schek
źródło
6

Tak,

jest to powszechne, ale to nie znaczy, że nie powinieneś walczyć w dobrej walce. Oto kilka kroków, w jaki sposób możesz zwiększyć bezpieczeństwo swojego serwera.

Unikaj adresów IP powiązanych z DNS

Możesz znacznie zmniejszyć tę liczbę w środowiskach współdzielonych lub kolokacyjnych, wyłączając dostęp SSH na dowolnych adresach IP powiązanych z nazwami domen. Niepubliczne adresy IP nienależące do domeny będą otrzymywać mniej tego rodzaju ruchu, więc kup niepubliczne adresy IP i używaj tego adresu IP tylko w celu uzyskania dostępu SSH.

Użyj VPN dla całego dostępu SSH

Jeśli znajdujesz się w środowisku, w którym możesz zaimplementować IPsec / VPN do sieci prywatnej w środowisku serwera, jest to idealne rozwiązanie. Wyłącz dostęp do Internetu SSH, upewnij się, że masz zintegrowane rozwiązanie wyłączania oświetlenia. Skonfiguruj VPN i zezwalaj na dostęp SSH tylko z VPN.

Wdrożenie reguł adresów IP dla dostępu SSH

Jeśli sieć VLAN nie jest opcją, skonfiguruj router lub reguły zapory, aby zezwalać tylko na połączenia SSH ze znanego zakresu adresów IP.

Jeśli wykonasz te kroki, będziesz spać znacznie łatwiej w nocy, wiedząc, że ktoś będzie musiał naruszyć sieć firm hostingowych, aby uzyskać dostęp do serwera przez SSH.

Ben DeMott
źródło
5

Całkiem normalne, aby zobaczyć setki nieudanych połączeń SSH.

Jeśli masz taką opcję, po prostu zmieniam mój port SSH na coś niestandardowego. Niekoniecznie sprawia, że ​​serwer jest bardziej bezpieczny, ale z pewnością czyści dzienniki (i pozwala zobaczyć, jak ktoś celowo próbuje się włamać!)

Adrian Macneil
źródło
5

Oprócz korzystania z automatycznego mechanizmu blokowania, takiego jak fail2ban, masz jeszcze jedną opcję: w rzeczywistości skontaktuj się z adresem ISP atakującego. Może się to wydawać całkowicie bezcelowe, ale w przypadku skrypciarza ich dostawca usług internetowych jest bardziej niż chętny do podjęcia działań w stosunku do nich.

Aby znaleźć adres do nadużyć, zacznij od arin.net i wyszukaj adres IP za pomocą whois. Możesz zostać przekierowany do innego rejestru regionalnego, ale w końcu możesz znaleźć odpowiedzialnego usługodawcę internetowego dla bloku IP zawierającego adres. Poszukaj adresu @ nadużycia lub po prostu napisz kontakt techniczny.

Wyślij im uprzejmą wiadomość z odpowiednimi wpisami pliku dziennika (pamiętaj, aby usunąć wszelkie prywatne informacje) i poproś ich o podjęcie działań przeciwko przestępcy.

JRW
źródło
4
Robiliśmy to kiedyś. Jednak ilość czasu spędzonego w porównaniu z otrzymaną korzyścią była tak niewielka, że ​​nie ma znaczenia.
NotMe,
1
Wariantem tej taktyki, która jest bardziej skuteczna, ale o wiele bardziej ryzykowna, jest zgłoszenie dostawcy usług internetowych do węzła pośredniego. Ale MUSISZ mieć solidne dowody z raportu. Raz to zrobiłem, ponieważ cały ISP miał poważne kłopoty, ponieważ ignorowali swoje zgłoszenia o nadużyciach.
staticsan
1
Pewnego razu to zrobiłem, wiadomość o nadużyciach dotarła do hakera zamiast do kogoś odpowiedzialnego za serwery. Od tego czasu nie przejmuję się już, po prostu zbyt wielkim problemem.
wump
To naprawdę nie pomoże w większości przypadków i może być czasochłonne
RichVel
4

Odradzam korzystanie z fail2ban, ale uruchamianie SSH (i innych) na niestandardowym porcie. Nie wierzę w bezpieczeństwo przez zaciemnienie, ale uważam, że jest to doskonały sposób na zmniejszenie hałasu w dziennikach.

Nieudane logowanie na niestandardowych portach będzie nieliczne i może oznaczać również bardziej ukierunkowane ataki.

Możesz nawet pójść o krok dalej i zainstalować honeypot SSH, taki jak Kippo, aby „wpuścić” bruteforcerów i zobaczyć, co zrobiliby, mając szansę.

Andy Smith
źródło
Haha, Kippo wygląda bardzo ładnie. Zamierzam zainstalować go na serwerze, aby zobaczyć, co próbują zrobić.
wump
4

Tak, to normalne. Co mówię klientom w twojej sytuacji z małymi stronami internetowymi.

Zawsze bądź przygotowany na włamanie.

Posiadaj kopię swojej strony na serwerze deweloperskim. Może to być pulpit systemu Windows za pomocą XAMPP, który można uzyskać za darmo.

ZAWSZE wprowadzaj zmiany na serwerze deweloperskim, a następnie przesyłaj je na swoją stronę internetową. Jeśli jest to CMS, taki jak Wordpress, umieść swoje posty na serwerze deweloperskim, a następnie skopiuj i wklej je na serwerze na żywo.

NIGDY nie pobieraj niczego z witryny na żywo na serwer programisty.

Regularnie monitoruj strony internetowe pod kątem wszelkich zmian, których nie wprowadziłeś. W szczególności ukryte linki do narkotyków lub produktów „ulepszających”. Możesz znaleźć wiele dodatków do przeglądarki i programów, które zrobią to za Ciebie.

Jeśli jesteś zagrożony. Powiadom hosta, usuń wszystko, zmień wszystkie hasła i prześlij swój czysty serwer programistów na pusty serwer. Współpracuj z gospodarzem, aby zapobiec ponownemu wystąpieniu.

W przypadku małej witryny nie powinieneś potrzebować zespołu bezpieczeństwa. To właśnie powinien zapewnić Twój host. Jeśli nie, zdobądź inny host, co jest o wiele łatwiejsze, gdy masz serwer deweloperski niż próbować przenieść serwer na żywo.

Mam nadzieję że to pomoże.

J Litten
źródło
2
+1 za „Zawsze bądź przygotowany na włamanie”.
user78940
3

Inny sposób na zatrzymanie go (ponieważ osobiście nie lubię przenosić portu SSH): zdecyduj, czy możesz wyświetlić listę wszystkich sieci, z których kiedykolwiek będziesz chciał się zalogować, a następnie zezwól tylko tym na dostęp do twojego portu SSH.

Wpisy WHOIS lokalnych dostawców usług internetowych pomogły mi zredukować ataki do 1-2 prób logowania na miesiąc (wtedy było to około 1 000 dziennie). Wykryłem je, wciąż używając denyhosts .

weeheavy
źródło
3

Oprócz innych doskonałych sugestii, które już otrzymałeś, lubię również stosować dyrektywę AllowUsers, jeśli jest to odpowiednie dla danego serwera. Pozwala to tylko określonym użytkownikom na logowanie za pośrednictwem SSH, co znacznie zmniejsza możliwość uzyskania dostępu za pośrednictwem niepewnie skonfigurowanego konta gościa / usługi / systemu.

Przykład:

AllowUsers admin jsmith jdoe

Opcja AllowUsers określa i kontroluje, którzy użytkownicy mogą uzyskać dostęp do usług ssh. Można określić wielu użytkowników, oddzielonych spacjami.

Sójka
źródło
3

Tak, to normalne. Możesz :

  • Zmniejsz szansę na atak za pomocą fwknop

Fwknop jest jedną z lepszych implementacji knock portowych, ponieważ nie jest sfałszowany i faktycznie uwierzytelnia się, a nie tylko autoryzuje połączenie.

  • Możesz zmienić port używany przez openssh, ale tak naprawdę nie poprawiasz bezpieczeństwa.

  • Wzmocnij uwierzytelnianie ssh za pomocą Google -hententator lub wikid

Chroni to ataki oparte na hasłach oraz możliwość zdecydowanego ataku / ataku ukierunkowanego, który naruszy twój komputer administracyjny i wykradnie kombinację klucza i hasła ssh.

Wystarczy spojrzeć na najnowszą wersję pwn2own, aby przekonać się, jak łatwo jest wyszkolonemu napastnikowi skompromitować w pełni załataną skrzynkę administracyjną.

Hilton D.
źródło
1

Niestety jest to całkiem normalne. Powinieneś rozważyć dodanie do systemu czegoś takiego jak fail2ban , aby automatycznie wykrywać i blokować atakujących. Jeśli jeszcze tego nie zrobiłeś, powinieneś rozważyć użycie tylko ssh z kluczami publicznymi i nie zezwalaj na logowanie roota przez ssh. Jeśli używasz ftp do przesyłania plików do systemu, rozważ użycie scp / sftp.

użytkownik619714
źródło
1

Zaimplementowałem pukanie portów i mam kilka sond dziennie. Nie dostają połączenia, więc odchodzą. Rejestruję i zgłaszam cały dostęp do danych portów.

Uruchomiłem również fail2ban z Shorewall jako zaporę, aby tymczasowo umieścić na czarnej liście upartych napastników.

Jeśli nie potrzebujesz dostępu do Internetu do SSH, wyłącz go. Jeśli masz kilka znanych adresów wymagających zdalnego dostępu, ogranicz dostęp do tych adresów.

Pomocne może być również ograniczenie dostępu do autoryzowanych kluczy.

BillThor
źródło
0

Używam pam_abldo tymczasowego umieszczania na czarnej liście brutalnych siłowników i działa to świetnie. Myślę, że lepiej jest mieć autoryzację w PAM przy użyciu własnej bazy danych niż polegać na hosts.denylub iptables.

Kolejnym plusem jest to, że pam_ablnie zależy od skanowania plików dziennika.

Christoffer Hammarström
źródło
0

Obecnie jest to całkowicie normalne.
Możesz ustawić limit „burst” na zaporze ogniowej dla nowych połączeń przychodzących na porcie SSH
lub zainstalować jeden z wielu parserów dziennika a'la fail2ban lub zmienić port SSH;).

Ostatni jest najłatwiejszy. Na maszynach o dużym obciążeniu takie próby włamania mogą mieć bardzo zły wpływ na cały system.

-
Pozdrawiam,
Robert

Robert
źródło
0

Tak, to normalne.

Właśnie zmieniłem port ssh z dala od standardowego 22. Mój serwer, moje zasady :) po prostu edytuj / etc / ssh / sshd_config, zmień port i zrestartuj usługę. Jedynym minusem jest to, że musisz pamiętać, aby dodać ten port do konfiguracji do każdego używanego klienta ssh.

Jan
źródło
0
  • Wyłącz logowanie roota (w każdym systemie root istnieje użytkownik root, więc boty mogą łatwo odgadnąć nazwę użytkownika). Po zalogowaniu się jako zwykły użytkownik możesz przełączyć się na rootowanie przez su lub sudo.

  • zmień domyślny port z 22

  • Zezwalaj na dostęp ssh tylko ze znanych adresów IP

  • Użyj silnego hasła alfanumerycznego dla użytkownika z dostępem ssh

Kevin Parker
źródło