Najbardziej prawdopodobnym powodem jest utrudnienie osobom, które próbują brutalnie wymusić logowanie SSH, jakie mogą znaleźć. Moja maszyna internetowa korzysta z domyślnego portu SSH, a moje dzienniki były wypełnione takimi rzeczami (wyciąg z rzeczywistego pliku dziennika):
sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96
Obecnie używam DenyHosts do blokowania adresów IP, które nie uwierzytelniają się zbyt wiele razy, ale prawdopodobnie równie łatwo jest po prostu zmienić porty; praktycznie wszystkie tego rodzaju ataki siłowe nie będą kłopotać się skanowaniem, aby sprawdzić, czy twój sshd nasłuchuje na innym porcie, po prostu założą, że nie korzystasz z jednego portu i przejdziesz dalej
Jeśli twoja konfiguracja sshd nie jest wystarczająca, aby zmierzyć się z głupimi dzieciakami skryptującymi próbującymi tylko portu 22, to i tak masz problem.
Bardziej racjonalną reakcją byłoby:
upewnij się, że użytkownicy używają dobrych haseł, trudnych do odgadnięcia / brutalnej siły
wyłącz uwierzytelnianie hasłem (przynajmniej dla ważnych kont) i po prostu użyj uwierzytelnienia kluczem publicznym
uważaj na problemy z bezpieczeństwem ssh i aktualizacje
Niektóre osoby mogą być również zirytowane hałasem zapisywanym przez sshd w dzienniku systemowym, np .:
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
Może być kuszące, aby zasłonić port sshd lub użyć rozwiązania automatycznego blokowania (takiego jak DenyHosts, Fail2ban lub BlockHosts) w celu ponownego zwiększenia stosunku sygnału do szumu .
Ale istnieją lepsze alternatywy. Na przykład, możesz skonfigurować demona syslog tak, aby szum dziennika sshd był zapisywany tylko - powiedzmy - /var/log/sshd-attempts.loga sygnał (tj. Pozostałe komunikaty dziennika sshd) był zapisywany w /var/log/messagesitd. Jak poprzednio.
Wdrożenie automatycznych narzędzi blokujących należy traktować ostrożnie, ponieważ dodanie większej złożoności systemów zabezpieczenia odpowiednich środków także zwiększenie ryzyka z eksploatacji . I rzeczywiście, z biegiem lat istnieje kilka raportów podatności na atak DoS dla każdego DenyHosts , Fail2ban i BlockHosts .
Naprawdę nie zgadzam się z tym, że „to bezpieczeństwo przez zaciemnienie”. Myślę, że ta odpowiedź jest częstym błędem w tym przypadku. @ Rozumowanie Michaela ogólnie pokazuje, że jest to lepszy powód, aby mieć go gdzie indziej. To głównie po to, aby pozbyć się wszystkich ataków z użyciem skryptów. Nie musi to oznaczać, że się ich boisz lub uważasz, że jest skuteczny przeciwko zdecydowanemu atakującemu. Wiem, że nigdy się nie martwiłem, że rzeczywiście wejdą. Ale wszystkie kłody były kłopotliwe.
ksenoterrakid
1
@xenoterracide: Jeśli martwisz się tylko o czytelność twoich plików dziennika, istnieją inne lepsze alternatywy, aby wykluczyć hałas zamiast zmieniać port jako taktykę zaciemniania, co było pytaniem. Jeśli chodzi o blokowanie adresów IP, co nie było częścią pytania: należy pamiętać, że zwiększenie złożoności systemów związanych z bezpieczeństwem oznacza również zwiększenie ryzyka wykorzystania. Rozważmy na przykład seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Tak, wpłynęło to na DenyHosts.
maxschlepzig,
1
Chodzi o coś więcej niż tylko czytelność. Prawidłowo udokumentowana zmiana portu nie stanowi zabezpieczenia przez zaciemnienie.
ksenoterrakid,
4
Zmiana portu SSH to głównie teatr bezpieczeństwa . Daje to niewyraźne wrażenie, że coś zrobiłeś. Ukryłeś port SSH pod wycieraczką.
Jeśli uruchomisz serwer SSH w Internecie, w dziennikach zobaczysz wiele nieudanych prób logowania, od botów, które szukają głupio słabych haseł, słabych kluczy i znanych exploitów w starszych wersjach serwerów. Nieudane próby to po prostu: nieudane próby. Jeśli chodzi o ocenę stopnia narażenia, są one całkowicie nieistotne. Musisz się martwić udanymi próbami włamań i nie zobaczysz ich w swoich logach.
Zmiana domyślnego portu zmniejszy liczbę trafień przez takie boty, ale tylko udaremni najmniej wyrafinowanych atakujących, którzy są zatrzymywani przez jakiekolwiek przyzwoite zabezpieczenia (aktualizacje zabezpieczeń są stosowane regularnie, dość silne hasła lub wyłączone uwierzytelnianie hasła). Jedyną zaletą jest zmniejszenie objętości dzienników. Jeśli jest to problem, weź pod uwagę coś takiego jak Denyhosts lub Fail2ban, aby zamiast tego ograniczyć szybkość połączenia, poprawi to również przepustowość.
Zmiana domyślnego portu ma poważną wadę: zmniejsza prawdopodobieństwo zalogowania się za zaporą ogniową. Zapory ogniowe częściej przepuszczają usługi na domyślnym porcie niż na jakimś losowym innym porcie. Jeśli nie korzystasz z serwera HTTPS, rozważ włączenie nasłuchiwania SSH również na porcie 443 (lub przekieruj przychodzące żądania TCP z portu 443 na port 22), ponieważ niektóre zapory zezwalają na ruch, którego nie mogą zdekodować na porcie 443, ponieważ wygląda jak HTTPS.
Odpowiedzi:
Najbardziej prawdopodobnym powodem jest utrudnienie osobom, które próbują brutalnie wymusić logowanie SSH, jakie mogą znaleźć. Moja maszyna internetowa korzysta z domyślnego portu SSH, a moje dzienniki były wypełnione takimi rzeczami (wyciąg z rzeczywistego pliku dziennika):
Obecnie używam DenyHosts do blokowania adresów IP, które nie uwierzytelniają się zbyt wiele razy, ale prawdopodobnie równie łatwo jest po prostu zmienić porty; praktycznie wszystkie tego rodzaju ataki siłowe nie będą kłopotać się skanowaniem, aby sprawdzić, czy twój sshd nasłuchuje na innym porcie, po prostu założą, że nie korzystasz z jednego portu i przejdziesz dalej
źródło
Nie, jest to taktyka bezpieczeństwa .
Jeśli twoja konfiguracja sshd nie jest wystarczająca, aby zmierzyć się z głupimi dzieciakami skryptującymi próbującymi tylko portu 22, to i tak masz problem.
Bardziej racjonalną reakcją byłoby:
Niektóre osoby mogą być również zirytowane hałasem zapisywanym przez sshd w dzienniku systemowym, np .:
Może być kuszące, aby zasłonić port sshd lub użyć rozwiązania automatycznego blokowania (takiego jak DenyHosts, Fail2ban lub BlockHosts) w celu ponownego zwiększenia stosunku sygnału do szumu .
Ale istnieją lepsze alternatywy. Na przykład, możesz skonfigurować demona syslog tak, aby szum dziennika sshd był zapisywany tylko - powiedzmy -
/var/log/sshd-attempts.loga sygnał (tj. Pozostałe komunikaty dziennika sshd) był zapisywany w/var/log/messagesitd. Jak poprzednio.Wdrożenie automatycznych narzędzi blokujących należy traktować ostrożnie, ponieważ dodanie większej złożoności systemów zabezpieczenia odpowiednich środków także zwiększenie ryzyka z eksploatacji . I rzeczywiście, z biegiem lat istnieje kilka raportów podatności na atak DoS dla każdego DenyHosts , Fail2ban i BlockHosts .
źródło
Zmiana portu SSH to głównie teatr bezpieczeństwa . Daje to niewyraźne wrażenie, że coś zrobiłeś. Ukryłeś port SSH pod wycieraczką.
Jeśli uruchomisz serwer SSH w Internecie, w dziennikach zobaczysz wiele nieudanych prób logowania, od botów, które szukają głupio słabych haseł, słabych kluczy i znanych exploitów w starszych wersjach serwerów. Nieudane próby to po prostu: nieudane próby. Jeśli chodzi o ocenę stopnia narażenia, są one całkowicie nieistotne. Musisz się martwić udanymi próbami włamań i nie zobaczysz ich w swoich logach.
Zmiana domyślnego portu zmniejszy liczbę trafień przez takie boty, ale tylko udaremni najmniej wyrafinowanych atakujących, którzy są zatrzymywani przez jakiekolwiek przyzwoite zabezpieczenia (aktualizacje zabezpieczeń są stosowane regularnie, dość silne hasła lub wyłączone uwierzytelnianie hasła). Jedyną zaletą jest zmniejszenie objętości dzienników. Jeśli jest to problem, weź pod uwagę coś takiego jak Denyhosts lub Fail2ban, aby zamiast tego ograniczyć szybkość połączenia, poprawi to również przepustowość.
Zmiana domyślnego portu ma poważną wadę: zmniejsza prawdopodobieństwo zalogowania się za zaporą ogniową. Zapory ogniowe częściej przepuszczają usługi na domyślnym porcie niż na jakimś losowym innym porcie. Jeśli nie korzystasz z serwera HTTPS, rozważ włączenie nasłuchiwania SSH również na porcie 443 (lub przekieruj przychodzące żądania TCP z portu 443 na port 22), ponieważ niektóre zapory zezwalają na ruch, którego nie mogą zdekodować na porcie 443, ponieważ wygląda jak HTTPS.
źródło