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.
Jestem jedynym użytkownikiem tego serwera. Dziękujemy za wyjaśnienie problemu 1024+. Gdybym wybrał, użyłbym portu 48xxx. W każdym razie nadal nie rozumiem, czy jest to przydatne czy nie = /
dynamic
16
+1 dla> 1024 bitów.
MattC
26
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.
„sprawdź wszystkie możliwe 64k portów” ... Uruchomienie SSH na dowolnym porcie powyżej 1023 jest po prostu nieprawidłowe. To sprawia, że system jest bardziej wrażliwy niż pozostawianie go uruchomionego w domyślnym porcie.
Juliano,
3
@Juliano - proszę wyjaśnić. Tylko dlatego, że musisz być rootem, aby nasłuchiwać na uprzywilejowanym porcie, (AFAIK) nie sprawia, że uruchomienie na nieuprzywilejowanym porcie jest niebezpieczne .
Alnitak,
4
Nawiasem mówiąc, nie jest to bezpieczeństwo poprzez zaciemnienie, w przeciwnym razie będziesz musiał również wywołać to samo uwierzytelnienie hasła. Bezpieczeństwo wynikające z niejasności występuje wtedy, gdy implementacja nie jest ujawniona. Tutaj implementacja jest jasno określona (to jest „zmieniłem port usługi”), a sekret („który port?”) Jest nadal tajny.
Juliano,
5
@John - właściwie rozumiem punkt @ Juliano. Nie powoduje to, że sam demon SSH jest wewnętrznie mniej bezpieczny, ale w ogólnym przypadku uruchomienie na nieuprzywilejowanym porcie unieważnia normalne założenie, że root uruchomił demona. Jeśli więc możesz w jakiś sposób zatrzymać tego demona (np. Poprzez DoSing go), możesz uruchomić własnego fałszywego demona na jego miejscu bez potrzeby rootowania. Ten fałszywy demon może następnie przechwycić wystarczające szczegóły, aby umożliwić dalsze exploity.
Alnitak,
2
@John, to prawda - nadal atakujący musi mieć wystarczający dostęp do samodzielnego uruchomienia nowego demona. Kluczową kwestią jest to, że nie potrzebują już dostępu do roota, aby go uruchomić.
Alnitak,
21
Aby naprawdę uniknąć ataków bruteforce, zawsze należy wykonać następujące czynności:
Zainstaluj denyhosts lub fail2ban
Ogranicz liczbę połączeń na sekundę na porcie ssh
Zmień port ssh
Odmowa logowania do roota
Włącz uwierzytelnianie za pomocą klucza zamiast hasła
Wydaje się, że to dobra lista, z wyjątkiem części zmiany portu, z którą tak naprawdę się nie zgadzam, to zbyt duże niejasności. Nowoczesny skaner portów i tak go znajdzie w ciągu kilku sekund? (i wiele sieci nie pozwala na losowy ruch portów, zwykle ograniczony do powiedzmy 22, 80 i 443)
Oskar Duveborn
1
Limit zmiany portu ataki typu brute force, które sprawdzają, czy ssh działa na domyślnym porcie, cóż, jeśli atak jest poważniejszy, tylko w tym przypadku atakujący może wykonać skanowanie portów dziur w twojej sieci / hostach.
Ali Mezgani
1
W rzeczywistości uważam, że za dobrą zaporą ogniową, jeśli będziesz aktualizować swoje usługi i zmienisz ich domyślne ustawienie, możesz być bezpieczny przed atakami złośliwych ludzi. i może nie pochodzić z exploitów
0day
2
Użycie denyhosts / fail2ban zmniejsza potrzebę przełączania portów lub wymaga kluczy. Jeśli nie zezwalasz na hasła, nie ma sensu używać denyhosts / fail2ban lub zmiany portów.
Jeremy L
1
Korzystanie z denyhosts / fail2ban niekoniecznie zmniejsza potrzebę dodatkowych środków bezpieczeństwa. Bezpieczeństwo polega na stworzeniu jak największej liczby blokad dla użytkowników, którzy próbują obejść zabezpieczenia. Pewnie, że prawdopodobnie nie musisz zmieniać portu z 22 na 2222, ale powiedz, że pojawia się inny administrator i ponownie włącza hasło ... nadal będziesz mieć kilka innych progów prędkości. Każdy krok wymieniony powyżej przybliża administratorowi procent niemożności 100% bezpieczeństwa.
Patrick R
12
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.
Ale spójrz na odpowiedź Davida Spilletta, aby dowiedzieć się, dlaczego port 1291 (większy niż 1024) może być niebezpieczny.
Konerak,
Jeśli zamierzasz doradzić korzystanie z nieuprzywilejowanego portu 2 lata po wielu innych, lepszych odpowiedziach - być może przygotujesz lepszy powód niż „Widziałem, jak firmy to robią”. Widziałem, jak firmy robią wiele rzeczy. Rzadko chcę iść za ich przykładem.
underscore_d
11
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:
99,9999% ataków siłowych przeprowadzane są przez boty, które szukają tylko portu 22 i nigdy nie marnują czasu na próby wykrycia niestandardowego portu. Ataki typu brute-force i środki zaradcze, takie jak denyhosts lub fail2ban, zużywają zasoby, które można zaoszczędzić, po prostu uruchamiając serwer ssh na niestandardowym porcie.
Pozbędziesz się wszystkich niepotrzebnych raportów o botach próbujących włamać się do twojego systemu. Jeśli w raporcie nieudanych logowań pojawi się jakikolwiek adres IP, istnieje prawdopodobieństwo, że jest to człowiek.
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.
Może to jednak skutkować jeszcze większą liczbą zgłoszeń do pomocy technicznej.
Brad Gilbert
3
To prawda, ale zwiększone bezpieczeństwo ma swoją cenę. :)
Born To Ride
11
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.
Tak. Kiedy miałem ssh na porcie 22, miałem ponad 20000 nieudanych prób wprowadzenia hasła w dziennikach. Co oznaczało, że codziennie otrzymuję e-mail z ostrzeżeniem dotyczącym bezpieczeństwa. Miałem wyłączone uwierzytelnianie hasłem - musiałeś mieć odpowiedni klucz prywatny, aby się zalogować - więc nie martwiłem się, że ktoś wejdzie, ale wolę otrzymywać e-maile z ostrzeżeniem o bezpieczeństwie tylko wtedy, gdy dzieje się coś prawdziwego.
jdege
10
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.
nie wspominając o tym, że skaner portów spróbuje również innych portów.
Jim Deville,
4
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.
Jeśli jesteś / całkowicie bezużyteczny / całkowicie bezużyteczny dla bezpieczeństwa /, zgodziłbym się. Zmiana portu jest jednak przydatna do ograniczenia szumów w dzienniku uwierzytelniania.
Chris S
„i wymaga uwierzytelnienia na podstawie klucza”? co to jest
dynamiczny
1
@ yes123, SSH może używać par kluczy publiczny-prywatny do uwierzytelnienia użytkownika zamiast hasła. Para kluczy może być również chroniona hasłem, oferując w ten sposób uwierzytelnianie dwuskładnikowe (coś, co znasz = hasło; coś, co masz = plik klucza). Jeśli to zaimplementujesz, możesz wyłączyć logowanie haseł (w ten sposób osoba znająca hasło lokalne nie będzie mogła uzyskać dostępu do pliku klucza i hasła pliku klucza). Hasła są względnie niepewne w porównaniu z kluczami, miliony razy łatwiej jest użyć brutalnej siły niż pary kluczy (choć zwykle wciąż trudne). Zobacz man ssh-keygenwiele informacji.
Chris S
@ yes123, przydatne są różne strony man związane z ssh (sshd, sshd_config, ssh, ssh_config). Ten dokument wygląda jak dobry samouczek na temat uwierzytelniania klucza publicznego za pomocą ssh.
larsks
2
Mimo, że wyglądam jak typowe „zabezpieczenie przez zaciemnienie”, uważam, że ma to sens, ponieważ skanowanie wszystkich możliwych portów (~ 64 tys.) Jest znacznie bardziej czasochłonne niż tylko jeden z nich.
Ale mogę dodać, że „pukanie portów” jest znacznie lepsze.
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).
Dobry pomysł z portem do przodu, John! Myślę, że oboje się czegoś nauczyliśmy :)
Alnitak
1
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.
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.
-1, nie do końca rozumiesz, czym jest niejasność ... Robienie czegoś nieoczywistego to nie to samo, co blokowanie go. Chociaż prawdą jest, że żadne bezpieczeństwo nie jest absolutne, zdecydowanie istnieją różnice, a utrudnione uwierzytelnianie trójczynnikowe w nicości nie pomaga nikomu.
Chris S
1
Przepraszam, Chris, to religia kultowa. Może nie możesz wybrać zamka, a więc pomyśleć, że posiadanie go zapewnia bezpieczeństwo, ale wszystkie zamki można wybrać. Myśl nieszablonowo: w wielu przypadkach uczynienie czegoś „nieoczywistym” może być lepsze niż użycie zamka. Twój model / widok bezpieczeństwa jest jak pozostawienie laptopa w zamkniętym samochodzie z ustawionym budzikiem - jeden tweaker z kamieniem i twój laptop zniknął. Ale może to nie jest tweaker, ale ktoś, kto ma 0-dniowy exploit i czas na zabicie ... Och, patrz! Chris ma „bezpieczny” i dość widoczny cel! Nieprzejrzystość jest BARDZO ważną częścią bezpieczeństwa.
losowy Joe
Przepraszam, ale twoje porównania i logika po prostu nie wytrzymują. Wiem, jak wybierać zamki, szybciej je odciąć, wybić okno, przejść. Każdy środek bezpieczeństwa wymaga pewnego czasu i wysiłku, aby go obejść; niejasność zajmuje niewiele czasu i wysiłku, rzędu minut do godzin. Prawdziwe bezpieczeństwo, takie jak próby ograniczenia hasła przy próbie hasła, powodują, że przejście przez hasło zajmuje dużo czasu. Ta znacząca różnica czasu stanowi różnicę między „fałszywym” bezpieczeństwem a „prawdziwym”; w tym pierwszym pojawia się niejasność.
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.
źródło
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.źródło
Aby naprawdę uniknąć ataków bruteforce, zawsze należy wykonać następujące czynności:
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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) .
źródło
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.
źródło
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.źródło
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.
źródło
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.
źródło
man ssh-keygenwiele informacji.Mimo, że wyglądam jak typowe „zabezpieczenie przez zaciemnienie”, uważam, że ma to sens, ponieważ skanowanie wszystkich możliwych portów (~ 64 tys.) Jest znacznie bardziej czasochłonne niż tylko jeden z nich.
Ale mogę dodać, że „pukanie portów” jest znacznie lepsze.
źródło
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).
źródło
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.
źródło
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.
źródło
myślę, że jeśli jeszcze nie odkryłeś portu, który jest przydatny, w przeciwnym razie nie.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło