Odpowiedzi:
Nie jest to tak przydatne, jak twierdzą niektórzy ludzie, ale przynajmniej zmniejszy wpływ na twoje pliki dziennika, ponieważ wiele prób logowania przy użyciu brutalnej siły używa tylko domyślnego portu zamiast skanowania, aby sprawdzić, czy SSH nasłuchuje gdzie indziej. Niektóre ataki będą skanować w poszukiwaniu SSH gdzie indziej, więc nie jest to srebrna kula.
Jeśli twój serwer będzie jakimś współużytkowanym hostem, a nie tylko zaspokajaniem potrzeb twoich projektów, korzystanie z portu innego niż domyślny może być uciążliwe, ponieważ będziesz musiał go tłumaczyć użytkownikom w kółko gdy zapomną, a ich programy klienckie nie połączą się z portem 22!
Innym możliwym problemem z SSH na niestandardowym porcie jest spotkanie klienta z restrykcyjnym zestawem filtrów wychodzących, który nie może połączyć się z twoim niestandardowym portem, ponieważ jego filtr pozwala tylko na przykład na porty 22, 53, 80 oraz 443 jako miejsce docelowe nowych połączeń wychodzących. Jest to rzadkie, ale na pewno nie niespotykane. Podobnie niektórzy dostawcy usług internetowych mogą zobaczyć zaszyfrowany ruch na porcie innym niż ten, na którym jest to ogólnie oczekiwane (port 443 lub HTTPS, 22 dla SSH itd.), Jako próba ukrycia połączenia P2P i przepustnicy (lub blokady) połączenie w niewygodny sposób.
Osobiście trzymam SSH na standardowym porcie dla wygody. Dopóki stosowane są zwykłe środki ostrożności (silna polityka haseł / kluczy, ograniczenie logowania do roota, ...), nie trzeba się martwić, a problem wzrostu pliku dziennika, gdy zostaniesz uderzony brutalną siłą, można złagodzić za pomocą narzędzi takich jak jako fial2ban do tymczasowego blokowania hostów, które dają zbyt wiele złych zestawów danych uwierzytelniających w danym przedziale czasu.
Niezależnie od wybranego portu, jeśli odejdziesz od 22, upewnij się, że jest on poniżej 1024. W większości konfiguracji podobnych do Uniksa w ich domyślnej konfiguracji tylko root (lub użytkownicy w grupie root) mogą nasłuchiwać na portach poniżej 1024, ale każdy użytkownik może nasłuchiwać na wyższych portach. Uruchamianie SSH na wyższym porcie zwiększa ryzyko, że nieuczciwy (lub zhakowany) użytkownik zdoła zawiesić demona SSH i zastąpić go własnym lub proxy.
Jest to prosta (ale zaskakująco skuteczna) forma bezpieczeństwa poprzez zaciemnienie .
Jeśli twój serwer SSH nie znajduje się na porcie 22, prawdopodobieństwo znalezienia go przez osoby skanujące cały Internet w poszukiwaniu słabych haseł do kont domyślnych jest znacznie mniejsze. Jeśli skanujesz całą sieć, nie możesz sobie pozwolić na sprawdzenie wszystkich 64 tys. Możliwych portów, aby znaleźć serwer SSH.
Jednak jeśli ktoś aktywnie atakuje cię konkretnie, nie przynosi to żadnych korzyści, ponieważ proste jednorazowe nmapskanowanie ujawni port, na którym faktycznie działa.
Aby naprawdę uniknąć ataków bruteforce, zawsze należy wykonać następujące czynności:
Tak, jest to przydatne, ponieważ pomaga uniknąć wszystkich ataków brutalnej siły i pomaga utrzymać dzienniki w czystości :)
jeśli chodzi o numer portu, który zależy od ciebie, widziałem, że firmy używają 1291 dość często. Używam jednak czegoś wyższego, aby uniknąć niektórych skryptów.
Nie zezwalając na logowanie roota ssh i zmianę numeru portu i być może coś w rodzaju fail2ban i powinieneś być złoty. dodaj iptables, aby zachować dokładność i na bieżąco informować, a nie powinieneś mieć żadnych problemów.
Użycie niestandardowego portu ssh wymagałoby więcej wyjaśnień i dokumentacji, a odpowiedź na e-maile „Nie mogę się zalogować”.
Uważam, że następujące zalety uruchamiania sshd na niestandardowym porcie są ważniejsze niż problemy, które stwarza:
Co więcej, jeśli chcesz być naprawdę paskudny, zawsze możesz uruchomić fałszywy sshd (z DenyUsers * ) na standardowym porcie 22, podczas gdy twój zwykły sshd działa na porcie 54321. Zapewni to, że wszystkie boty i intruzi będą wiecznie spróbuj zalogować się do usługi, która odmawia logowania, ponieważ nikt nigdy nie pomyśli o próbie znalezienia prawdziwej usługi sshd.
Moje 2 centy.
Robienie tego z jakiegokolwiek „bezpieczeństwa” jest fałszywe. To najlepszy przykład bezpieczeństwa przez zaciemnienie, które nie jest bezpieczeństwem.
Jeśli chcesz, aby twoje dzienniki były nieco lżejsze i czystsze, to tak, jest to przydatne, ponieważ nie dostaniesz tylu prób pukania / próbowania brutalnej siły przez skrypty.
Uruchomiłbym ssh na standardowym porcie i użyłem czegoś takiego jak fail2ban lub denyhosts, aby ograniczyć liczbę ataków słownikowych.
Inną opcją jest wyłączenie logowania za pomocą haseł i zezwolenie na logowanie tylko za pomocą kluczy SSH.
Ponieważ istnieje wielu złych ludzi, którzy skanują wszystkie adresy IP serwerów w poszukiwaniu otwartych portów, próbując je wykorzystać. Przez cały dzień miałem ataki młotem na mój port SSH, dopóki nie przeniosłem go do innego portu i adresu IP, który nie był już powiązany z żadną z moich stron internetowych.
Przydaje się to w tym, że boty skryptowe, które próbują zgadywać hasła metodą brute-force, zwykle koncentrują się na Porcie 22, więc zmiana portów zwykle je wyrzuca. Będziesz musiał zrównoważyć wartość ograniczania tego ryzyka z bólem związanym z konfigurowaniem klientów ssh do łączenia się z niestandardowym portem (co nie jest zbyt dużym problemem, jeśli nie masz wielu użytkowników, co prawda).
Alternatywnie można zmniejszyć ryzyko brutalnej siły, wyłączając uwierzytelnianie za pomocą hasła i zamiast tego wymagając uwierzytelnienia za pomocą klucza RSA.
Zwykle nie zmieniam portu na dysku SSHD, więc nie mogę zasugerować innego numeru, ale sprawdź listę najczęściej używanych portów, aby znaleźć inny numer (tj. Taki, który nie jest używany przez coś innego, a zatem może zostać zeskanowany) .
Zawsze zmieniam SSHd na port 2222, każdy, kto musiałby dostać się na moje serwery, wie o tym i nie jest to tajemnicą. Robiąc to, nie ma absolutnie żadnego bezpieczeństwa (chyba że potencjalny haker jest absolutnym kretynem).
Jedyną korzyścią, jaką z tego czerpię, jest to, że dziennik uwierzytelnienia nie zawiera miliona nieudanych prób logowania do „root”, „alice”, „bob”, „sally”, „admin” itp.
Bezpieczeństwo przez zaciemnienie okazało się bezużyteczne, zwykle konfiguruję dostęp ssh ze standardowym portem ze wszystkich wyżej wymienionych powodów (problemy z konfiguracją klienta, problemy z zaporą ogniową i serwerem proxy itp.).
Poza tym zawsze wyłączam logowanie roota i uwierzytelnianie hasłem, a jako ostatni krok używam fail2ban, aby pozbyć się tych irytujących wiadomości w syslog. W Debian / Ubuntu jest to tak proste, jak pisanie aptitude install fail2ban. Domyślna konfiguracja działa całkiem dobrze, ale zwykle dostosowuję niektóre parametry, aby były bardziej restrykcyjne, mając dłuższy czas blokowania (co najmniej jeden dzień) i tylko 2 nieudane próby uwierzytelnienia jako wyzwalacz zakazu.
Powiedziałbym, że najbardziej chroniąc się przed zmianą portu SSH są zautomatyzowane skany, które spróbują uzyskać dostęp przy użyciu standardowych nazw użytkowników / haseł, jeśli zasady haseł są ścisłe, nie powinieneś się martwić im.
Jeśli wyłączysz logowanie do swojego hasła (co jest wysoce zalecane), zmiana portu SSH jest całkowicie bezużyteczna. Wyłączając logowanie haseł (i wymagając uwierzytelnienia opartego na kluczach), eliminujesz możliwość prób wprowadzenia hasła metodą brute-force, więc nic nie zyskujesz, szukając numerów portów.
Jeśli nadal zezwalasz na uwierzytelnianie za pomocą hasła, pozostawiasz otwartą na możliwość udanej próby użycia siły lub - co bardziej powszechne - z mojego doświadczenia - że twoje hasło zostało naruszone, ponieważ wpisujesz je podczas korzystania z działającego systemu keylogger.
man ssh-keygenwiele informacji.
Nie odpowiedź, ale za długa na komentarz, więc zrobię to CW.
Zastanawiałem się nad tym przez jakiś czas i doszedłem do wniosku, że w komentarzach do odpowiedzi Alnitaka jest wiele prawdy. Niemniej jednak uważam, że uruchomienie SSH na porcie 22 sprawia, że zbyt łatwo jest przeprowadzać przeciwko nim wszelkiego rodzaju ataki.
Aby rozwiązać ten problem, uruchamiam moje wewnętrzne serwery SSH na porcie 22 i używam zapory, aby przekierować wysoki port do 22 na komputerach docelowych. Zapewnia to pewne bezpieczeństwo poprzez zaciemnienie, przy jednoczesnym zachowaniu bezpieczeństwa niskiego portu, jak zauważył Juliano.
Bezpieczeństwo poprzez zaciemnienie nie jest regułą, którą zwykle popieram i często zaznacza się, że zwykłe skanowanie portów ujawni port docelowy, czyniąc zaciemnienie bezwartościowym. Aby rozwiązać ten problem z moimi zaporami ogniowymi (Smoothwall Express), zarówno w pracy, jak i w domu, użyj skryptu o nazwie Guardian Active Response, który jest uruchamiany przez alerty Snort. Z obserwacji mogę powiedzieć, że gdy trafisz więcej niż 3 różne porty z tego samego źródła, twoje pakiety są upuszczane do ustawionego czasu resetowania. To sprawia, że uruchomienie skanowania portów jest dość trudne i niezwykle czasochłonne, przez co zaciemnienie jest naprawdę warte czegoś. To w rzeczywistości spowodowało, że byłem tak często wyłączany w przeszłości, że ustawiłem wykluczenie dla mojego źródłowego adresu IP (domowego lub biurowego).
Problemem jest to, że zapora sieciowa jest skonfigurowana tak, aby zezwalała na łączenie się tylko niektórych adresów IP, a szef jest zmęczony otwieraniem określonych adresów IP, gdy jest poza domem. Jeśli blokujesz niektóre adresy IP w zaporze, może to być problem w dupie.
Dwie rzeczy, o których tu myślę. Zmiana portu chroni przed automatycznymi atakami. To tyle, ale to duża część średniego ruchu związanego z atakami ... zautomatyzowane skrypty skanujące sieci. Jeśli zmienisz domyślny port, ataki te powinny spaść do zera. W związku z tym ma to sens. Ale nie robi nic przeciwko ukierunkowanemu atakowi, ponieważ atakujący może po prostu skanować z Nessus lub NMAP, aby ustalić, jakich portów używasz, jeśli masz specjalnego małego przyjaciela, który wystarczająco cię nienawidzi.
Po drugie, jeśli używasz serwerów typu UNIX, możesz zainstalować narzędzie takie jak Denyhosts, aby zatrzymać ataki. Jeśli zainstalujesz denyhosts, monitoruje nieprawidłowe próby logowania, a po nieudanych próbach (bez względu na to, jaką liczbę określisz), zablokuje adres IP na określony czas. Denyhosts mogą również rozmawiać z innymi hostami denyhost i przekazywać listy blokad, więc jeśli atakujący zostanie zablokowany w systemie Linux Freda w Montanie, twój system również otrzyma ten adres IP do banowania. Bardzo przydatne, o ile użytkownicy pamiętają swoje hasła.
Wszystko zależy od scenariuszy użytkowania. Ile masz programów, które są „bolesne w dupę” dla zmiany portu połączenia dla SSH / SCP (a jeśli nie pozwalają na to lub sprawiają, że jest to uciążliwe, naprawdę musisz osobiście rozważyć zmianę dostawców). Jeśli to tylko potencjalny strach, powiedziałbym, że to nie problem. I to jest twój szef, który prosi o coś, co nie jest całkowicie zwariowane, ponieważ wielu sysadminów odwraca port SSH (z pewną dozą strachu od ludzi, którzy nienawidzą wszystkiego, co pachnie nawet słabo z powodu bezpieczeństwa ... ale to naprawdę ogranicza szum tła z automatycznych skanów).
Gotowany - zmiana portu blokuje automatyczne skrypty i większość złego ruchu. Nie zatrzyma ukierunkowanych napastników. Zastanów się również nad zainstalowaniem narzędzia do automatycznego banowania. Bezpieczeństwo w warstwach nie zaszkodzi, jeśli zostanie wykonane prawidłowo, a zmiana portów pomaga bardziej niż boli w większości sytuacji.
Używam SSH na porcie> 1024 od ponad 5 lat. Od tego czasu nie widzę żadnych prób skanowania portów w moim pliku dziennika (z wyjątkiem własnego). Są moje serwery, którymi administruję, które używają portu> 1024.
Wiele serwerów SSH, które działają na porcie> 1024, ma własne strony internetowe, które są dość popularne.
Jeśli serwer SSH działa w mojej własnej firmie, być może już podałem tutaj adres IP tego serwera, abyście mogli spróbować włamać się na serwer. Niestety serwer SSH nie jest mój. ;-)
Są jednak inne rzeczy, które należy skonfigurować, aby zapewnić bezpieczeństwo. Sam SSH> 1024 nie wystarczy. Numer portu nie może znajdować się w / etc / services, musi używać przekierowania portów (np. Port 1124-> 22), bezpośredni dostęp do roota musi być wyłączony i inne.
Więc jeśli chcesz się kłócić, lepiej uruchomić SSH na porcie> 1024 przez kilka lat.
p / s: 1124 nie jest moim numerem SSH. Ha ha.
Przeniesienie SSH do innego portu ma jakiś sens, pomaga w bezpieczeństwie, ale nie jest ogromne. Oczywiście, aby to zrobić, musisz mieć kontrolę nad zaporami ogniowymi, ale to nie jest problem. To, co moim zdaniem przewyższa korzyści płynące z przeniesienia portu, to otwarcie akceptowalnego zasięgu - w rzeczywistości powiedziałbym, że to więcej niż cofa korzyść i naraża cię dalej niż jesteś dzisiaj. Jestem pewien, że uda ci się go przekonać do przesunięcia portu ORAZ znacznego zmniejszenia zasięgu przychodzącego poprzez zebranie listy prawdopodobnych punktów wejścia zamiast otwierania ich wszystkich.
Zmiana portu ssh jest bezcelowym ćwiczeniem, które zapewnia jedynie ograniczone bezpieczeństwo. Lepiej jest po prostu wyłączyć uwierzytelnianie hasła, co eliminuje ryzyko prób wprowadzenia hasła przy użyciu siły, i polegać wyłącznie na uwierzytelnianiu opartym na kluczach ssh. Jeśli twoje środowisko wymaga uwierzytelnienia hasłem, zastosuj mechanizm dwuskładnikowy, taki jak SecurID lub Wikid.
Oba zapewniają prawdziwy wzrost bezpieczeństwa, a zmiana portu ssh daje jedynie złudzenie bezpieczeństwa.
Jest to praktyczne POV: Przez ponad cztery lata operowałem publicznie widocznymi prywatnymi serwerami ssh ze zmienionym portem SSH i nie miałem ani jednej próby skanowania hasła. Dla celów tej kontroli jakości właśnie włączyłem 22 z powrotem na jednym z nich na jeden dzień. W rezultacie skanowano mnie co około 10 minut z częstotliwością próby hasła około 5 na sekundę. Co więcej, „dzieciaki skanujące” również szukają serwerów z pewnymi podatnościami OpenSSH.
Na pewno jest to bezpieczeństwo przez zaciemnienie, które nie pomaga, jeśli masz wroga.
Działa świetnie, niezależnie od skomlenia tłumu „bezpieczeństwa przez zaciemnienie”.
Głupie króliki, WSZYSTKIE bezpieczeństwo to bezpieczeństwo poprzez zaciemnienie. Tylko dlatego, że uważasz, że niejasny protokół kryptograficzny Z [wymagający kombinacji próbek DNA, wspólnych kluczy i niemożliwego do wpisania przez ludzi hasła] jest rzeczywiście bezpieczny, nie czyni tego. Prawda jest taka, że każdy środek bezpieczeństwa opiera się na prawdopodobieństwach i założeniach użytkowników. Szkoda, jeśli wiem, jak wykorzystać to założenie, ale tak jest.
Tak czy siak,
Robiliśmy to od lat, a także a) ograniczając liczbę prób połączenia (nie wiem, jak to skonfigurowaliśmy, coś w konfiguracji ssh), oraz b) skrypt blokujący dowolny host uruchamiający atak słownikowy z więcej niż X błędne domysły za Y minut. Na pewien czas blokujemy nawiązywanie połączenia między hostem, a to ułatwia dostosowanie się do topologii zmieniających się sieci.
Jeśli twoje hasła są wystarczająco złożone i mogą wykonać 3 próby w ciągu 15 minut, nie ma się czego obawiać. Obserwowanie rozproszonych ataków również nie jest trudne - zwykle zestawiamy je według podsieci i adresu IP, aby wykluczyć tego rodzaju rzeczy.
Wreszcie, wszystko czego potrzebujesz to tajna metoda wiewiórki, aby umożliwić połączenia z twoim portem poprzez modyfikację reguł sprzętowych. Może to być wszystko ... zapytania smtp, web, magiczne dns. Rzeczy takie jak SecurID lub Wikid po prostu przekazują więcej informacji stronom trzecim. I nie zaczynaj od bezpiecznych certyfikatów za pośrednictwem stron trzecich.