Czy zmiana domyślnego numeru portu faktycznie zwiększa bezpieczeństwo?

69

Widziałem porady mówiące, że powinieneś używać różnych numerów portów dla prywatnych aplikacji (np. Intranet, prywatna baza danych, wszystko, czego żaden outsider nie użyje).

Nie jestem do końca przekonany, że może to poprawić bezpieczeństwo, ponieważ

  1. Istnieją skanery portów
  2. Jeśli aplikacja jest podatna na ataki, pozostaje taka bez względu na numer portu.

Czy coś przeoczyłem lub czy odpowiedziałem na własne pytanie?

Sam
źródło
30
Jedną rzeczą, którą zrobiłem, jest użycie niektórych domyślnych portów (np. SSH port 22) jako doniczki z miodem. Każdy, kto próbuje połączyć się z tymi portami, jest całkowicie zablokowany na xpewien czas. Okazało się skuteczne przeciwko skanowaniu portów. Oczywiście jest to tylko jedno narzędzie z przybornika bezpieczeństwa.
Belmin Fernandez,
Ogólne pytanie na temat bezpieczeństwa poprzez zaciemnienie jest zadawane tutaj: security.stackexchange.com/questions/2430/...
Tony Meyer
cóż, być może przeszkoda dla „skryptujących dzieci”
Łukasz Madon
1
@BelminFernandez, „jedno narzędzie w zestawie narzędzi bezpieczeństwa” ? Nie, służy to zmniejszeniu obciążenia serwera (wydajności) i nie ma nic wspólnego z bezpieczeństwem poza zwykłą iluzją. Ze względów bezpieczeństwa jest całkowicie niepotrzebne, jeśli serwer jest już silny, a jeśli serwer jest podatny na zagrożenia, nie czyni go bardziej bezpiecznym.
Pacerier
@Pacerier, zgodził się, że wysiłek i koncentracja powinny być na wdrażaniu bardziej solidnych praktyk bezpieczeństwa. Nie ma jednak powodu, dla którego nie można zrobić obu.
Belmin Fernandez

Odpowiedzi:

68

Nie zapewnia żadnej poważnej obrony przed atakiem ukierunkowanym. Jeśli twój serwer jest celem, wtedy, jak mówisz, przeskanują cię i dowiedzą się, gdzie są twoje drzwi.

Jednak przeniesienie SSH poza domyślny port 22 odstraszy niektóre ataki typu kiddie od atakowanych i amatorskich skryptów. Są to stosunkowo niewyszukani użytkownicy, którzy używają skryptów do skanowania portów dużych bloków adresów IP w tym samym czasie, aby sprawdzić, czy port 22 jest otwarty, a kiedy go znajdą, przeprowadzą na nim jakiś atak (brutalna siła, atak słownikowy, itp). Jeśli twoja maszyna znajduje się w tym bloku adresów IP, które są skanowane i nie działa SSH na porcie 22, to nie zareaguje, a zatem nie pojawi się na liście maszyn do zaatakowania przez tego skryptu. Ergo, zapewniono pewne zabezpieczenia na niskim poziomie, ale tylko dla tego rodzaju ataku oportunistycznego.

Na przykład, jeśli masz czas - zanurkuj na serwerze (zakładając, że SSH znajduje się na porcie 22) i wyciągnij wszystkie unikalne nieudane próby SSH, które możesz. Następnie usuń SSH z tego portu, poczekaj chwilę i ponownie rozpocznij nurkowanie w dzienniku. Bez wątpienia znajdziesz mniej ataków.

Kiedyś uruchamiałem Fail2Ban na publicznym serwerze internetowym i było to naprawdę, bardzo oczywiste, kiedy przestawiałem SSH z portu 22. To zmniejszyło ataki oportunistyczne o rząd wielkości.

jdw
źródło
3
Zgoda. Zauważyłem bardzo podobny spadek podczas eksperymentowania z przeniesieniem SSH na niestandardowy port. Na szczęście przy wyłączonym uwierzytelnianiu hasła, to naprawdę nie jest problem.
EEAA
3
Najlepsza odpowiedź tutaj. Wszystko sprowadza się do tego, kto atakuje. Kiedyś pomogłem administrować systemem, który został trafiony atakiem zero-dniowym od skanującego dzieciaka. Prawdopodobnie w MS-RDP, ponieważ nie mieliśmy IIS narażonych przez firewall. Nasz host nie pozwoliłby nam zmienić portu RDP (hosting zarządzany), więc w zasadzie musieliśmy tam siedzieć, podczas gdy pracowali nad nowym wzorcem filtrowania IDS / IPS. Chociaż może to nie pomóc w przypadku bardziej uznanych serwerów, takich jak SSH, które wydają się mieć mniej problemów bezpieczeństwa niż niektóre produkty MS.
Matt Molnar,
9
Zdecydowanie się zgadzam. Bezpieczeństwo polega na warstwach, a im więcej masz, tym bardziej jesteś bezpieczny. Może to być słaba warstwa, ale mimo to warstwa. Dopóki nie jest to oparte wyłącznie, może jedynie zwiększyć bezpieczeństwo.
Paul Kroon,
1
Innym punktem przeniesienia SSH poza port 22 jest to, że duża liczba prób SSH plus usług, ponieważ Fail2Ban może czasami zajmować cenny czas procesora. Może to być nieznaczne w stosunku do sprzętu linii, ale niektóre starsze serwery mogą doświadczać skoków procesora. Jego czas procesora, pamięć i przepustowość można wykorzystać do innych celów.
artifex
Zrobiłem to samo z RDP na Server 2003 - znacznie zmniejszyło liczbę nieudanych wpisów uwierzytelniania w Podglądzie zdarzeń.
Moshe
43

Utrzymywanie dzienników w czystości jest bardzo pomocne.

Jeśli zauważysz nieudane próby uruchomienia sshd na porcie 33201, możesz bezpiecznie założyć, że dana osoba jest celem ciebie i masz możliwość podjęcia odpowiednich działań, jeśli chcesz. Na przykład skontaktowanie się z władzami, zbadanie, kim może być ta osoba ( poprzez odniesienie do adresów IP zarejestrowanych użytkowników lub cokolwiek innego itp.

Jeśli użyjesz domyślnego portu, nie będzie wiadomo, czy ktoś cię atakuje, czy tylko przypadkowi idioci wykonują losowe skanowanie.

Thomas Bonini
źródło
8
wspaniałe wyróżnienie
ZJR
3
+1 To najlepszy argument na zmianę numerów portów, jaki kiedykolwiek słyszałem, i jak dotąd jedyna rzecz, która mnie do tego
zachęci
2
+1 To świetny punkt. Zagrożenia ukierunkowane są o wiele bardziej niebezpieczne niż losowe sondy (dzieci-skrypty przechodzą na łatwiejsze cele, jeśli masz jakieś przyzwoite zabezpieczenia). Atakowany cel może wiedzieć znacznie więcej na temat określonych luk w zabezpieczeniach, a nawet wzorców haseł. Dobrze jest móc rozpoznawać te ataki poza rojem spamu na porcie 22.
Steven T. Snyder
1
To nieprawda. Widziałem, że co najmniej jeden serwer został naruszony przez skanowanie na niestandardowym porcie SSH. Nie ma nieodłącznego powodu, dla którego osoba atakująca nie byłaby w stanie przeskanować również innych portów.
Sven Slootweg
@SvenSlootweg, Prawda, szczególnie gdy komputery stają się szybsze i tańsze, skanowanie trwające 65535 razy dłużej nie jest już dłużej .
Pacerier
28

Nie, nie ma. Nie całkiem. Terminem tym jest Security by Obscurity i nie jest to rzetelna praktyka. Masz rację w obu punktach.

Bezpieczeństwo od Obscurity w najlepszym przypadku powstrzyma przypadkowe próby, które polegają na szukaniu domyślnych portów, wiedząc, że w pewnym momencie znajdą kogoś, kto zostawił otwarte drzwi. Jeśli jednak kiedykolwiek staniesz przed jakimkolwiek poważnym zagrożeniem, zmień port deault, co najwyżej spowolni początkowy atak, ale tylko nieznacznie z powodu tego, co już wskazałeś.

Zrób sobie przysługę i pozostaw odpowiednio skonfigurowane porty, ale podejmij odpowiednie środki ostrożności, aby zablokować je za pomocą odpowiedniej zapory ogniowej, autoryzacji, list ACL itp.

squillman
źródło
17
Odwzorowanie (silnych) haseł i szyfrowania na ideę bezpieczeństwa przez zaciemnienie jest moim zdaniem
nieco rozciągłe
5
Używając tylko 8 znaków z pełnym zakresem znaków alfabetycznych i numerycznych (i nawet nie dopuszczając znaków specjalnych), liczba możliwych kombinacji wynosi 62 ^ 8 (213 340, 1055, 844,896). 65535 nie jest nawet w tym samym wszechświecie, nawet przy zastosowaniu detektorów skanowania portów. Uwaga: dyskontuję słabe hasła.
squillman
3
Znowu „nie jest tak, jakby niestandardowy port stanowił cały aparat bezpieczeństwa”. Każda odrobina pomaga. Jest to 10-sekundowa poprawka, która, jeśli nic innego, nie powstrzyma twojego serwera przed pojawieniem się komuś, kto szuka SSH i zacznie pukać do drzwi.
ceejayoz
8
Meh Śledzenie niestandardowych portów nie jest tego warte w mojej książce. Zgodzę się nie zgadzać z nikim ... Dodanie dalszych środków zaradczych poza zmianą portu jest z pewnością częścią równania i wolałbym pozostawić sprawy tym fragmentom układanki.
squillman
6
Z tego, co widziałem, niestandardowe porty stały się dość standardowe. 2222 dla ssh, 1080, 8080, 81, 82, 8088 dla HTTP. W przeciwnym razie staje się zbyt niejasny i zastanawiasz się, jaka usługa znajduje się na porcie 7201 i dlaczego nie możesz połączyć się z ssh na
7102.
13

Jest to niewielki poziom zaciemnienia, ale nie znaczący wzrost prędkości na drodze do włamania. Konfiguracja trudniejsza do obsługi długoterminowej, ponieważ wszystko, co komunikuje się z tą konkretną usługą, musi być powiedziane o innym porcie.

Dawno, dawno temu dobrym pomysłem było unikanie robaków sieciowych, ponieważ miały one tendencję do skanowania tylko jednego portu. Czas szybkiego mnożenia się robaka już minął.

sysadmin1138
źródło
2
+1 za trudniejszy problem z konfiguracją i wsparciem. Sprawia, że ​​tracisz czas, który można poświęcić na zabezpieczenie drzwi (zamiast szukać miejsca, w którym je umieściłeś).
Macke,
12

Jak zauważyli inni, zmiana numeru portu nie zapewnia większego bezpieczeństwa.

Chciałbym dodać, że zmiana numeru portu może faktycznie zaszkodzić twojemu bezpieczeństwu.

Wyobraź sobie następujący uproszczony scenariusz. Krakers skanuje 100 hostów. Dziewięćdziesiąt dziewięć z tych hostów ma usługi dostępne na tych standardowych portach:

Port    Service
22      SSH
80      HTTP
443     HTTPS

Ale jest też jeden host, który wyróżnia się z tłumu, ponieważ właściciel systemu próbował zaciemnić swoje usługi.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

To może być interesujące dla crackera, ponieważ skanowanie sugeruje dwie rzeczy:

  1. Właściciel hosta próbuje ukryć numery portów w swoim systemie. Być może właściciel uważa, że ​​w systemie jest coś cennego. To może nie być zwykły system.
  2. Wybrali niewłaściwą metodę zabezpieczenia swojego systemu. Administrator popełnił błąd, wierząc w zaciemnienie portu, co oznacza, że ​​może być niedoświadczonym administratorem. Być może użyli zaciemnienia portów zamiast odpowiedniej zapory ogniowej lub odpowiedniego IDS. Mogli również popełnić inne błędy bezpieczeństwa i mogą być narażeni na dodatkowe ataki bezpieczeństwa. Zbadajmy teraz trochę dalej, prawda?

Gdybyś był crackerem, czy rzuciłbyś okiem na jeden z 99 hostów obsługujących standardowe usługi na standardowych portach, czy na ten, który używa zaciemniania portów?

Stefan Lasiewski
źródło
14
Spojrzałbym na 99 gospodarzy, chyba że doświadczenie nauczyło mnie inaczej. Ktoś, kto przemieszcza porty, prawdopodobnie bardziej prawdopodobne jest załatanie i zabezpieczenie, jeśli mnie o to poprosisz.
ceejayoz
4
Spojrzałbym na jednego hosta, który się wyróżniał, z szansą, że niektórzy PFY pomyśleli: „Jeśli zmienię numery portów, JESTEM NIEWYKONANY!” ale hasło roota jest ustawione na „hasło”.
Andrew
3
@Ceejayoz, całkowicie się zgadzam. Korzystam z SSH na 2222, bez wartości bezpieczeństwa, ale znacznie ogranicza dzieciaków skryptów. Sądzę, że częściej mnie też ignorują, próbowali zmienić port, prawdopodobnie podjęli też inne kroki. Oczywiście nie wszystko jest konfiguracją domyślną ...
Chris S
1
Rozumiem, że nie wszyscy zgadzają się z moją opinią. Jednak z mojego doświadczenia wynika, że ​​wielu właścicieli systemów korzystało z zaciemniania portów, ale popełniali błędy, takie jak brak aktualizacji OpenSSH po ujawnieniu niektórych krytycznych luk w zabezpieczeniach lub używali niezaszyfrowanych kluczy SSH ze wspólnego systemu uniwersyteckiego itp. Niektóre z systemy te były soczystymi celami.
Stefan Lasiewski
3
Według rozszerzenia: przenosząc się do niestandardowego portu, bardziej zniechęcasz dzieciaków ze skryptów, ale także bardziej intrygujesz doświadczonego hakera. Co nasuwa pytanie: na kogo boisz się bardziej?
opóźnienie
9

Idę częściowo wbrew ogólnemu trendowi.

Samo przejście na inny port może dać ci kilka sekund podczas wyszukiwania, a tym samym nie zyskać nic w realnych warunkach. Jeśli jednak połączysz użycie niestandardowych portów ze środkami zapobiegającymi skanowaniu portów, może to naprawdę zwiększyć bezpieczeństwo.

Oto sytuacja, która dotyczy moich systemów: Usługi niepubliczne są uruchamiane na niestandardowych portach. Każda próba połączenia z więcej niż dwoma portami z jednego adresu źródłowego, niezależnie od tego, czy zakończy się powodzeniem, czy nie, w określonym czasie powoduje odrzucenie całego ruchu z tego źródła.

Pokonanie tego systemu wymagałoby szczęścia (trafienie w odpowiedni port przed zablokowaniem) lub rozproszonego skanu, który wyzwala inne środki, lub bardzo długiego czasu, który również zostałby zauważony i podjęty.

John Gardeniers
źródło
Połącz to z argumentem Andreasa Boniniego na temat ukierunkowanych ataków i jest to mocny argument za użyciem alternatywnych portów.
JivanAmara
5

Moim zdaniem przeniesienie portu, na którym działa aplikacja, wcale nie zwiększa bezpieczeństwa - po prostu z tego powodu, że ta sama aplikacja działa (z tymi samymi mocnymi i słabymi stronami) tylko na innym porcie. Jeśli aplikacja ma słabą stronę, przeniesienie portu, na którym nasłuchuje, do innego portu, nie rozwiązuje problemu. Co gorsza, aktywnie zachęca cię, byś NIE usuwał słabości, ponieważ teraz nie jest ciągle wbijany przez automatyczne skanowanie. Ukrywa prawdziwy problem, który należy rozwiązać.

Kilka przykładów:

  • „Czyści dzienniki” - wtedy masz problem z obsługą dzienników.
  • „Zmniejsza narzut związany z połączeniem” - Narzut jest albo nieistotny (jak większość skanów), albo potrzebujesz jakiegoś rodzaju filtrowania / eliminacji odmowy usługi wykonanej wcześniej
  • „Zmniejsza to narażenie aplikacji” - jeśli aplikacja nie jest w stanie sprostać zautomatyzowanemu skanowaniu i wykorzystaniu, oznacza to, że w aplikacji występują poważne niedociągnięcia w zakresie bezpieczeństwa, które należy usunąć (tj. Należy je załatać!).

Prawdziwy problem dotyczy administracji: ludzie oczekują, że SSH będzie mieć 22 lata, MSSQL 1433 i tak dalej. Przenoszenie ich to kolejna warstwa złożoności i wymaganej dokumentacji. Siedzenie w sieci i denerwowanie się przy pomocy nmap jest bardzo denerwujące, aby dowiedzieć się, gdzie zostały przeniesione. Dodatki do bezpieczeństwa są co najwyżej efemeryczne, a wady nie są nieznaczne. Nie rób tego Napraw prawdziwy problem.


źródło
2

Masz rację, że nie zapewni to większego bezpieczeństwa (ponieważ zakres portów serwera TCP ma tylko 16 bitów entropii), ale możesz to zrobić z dwóch innych powodów:

  • jak już powiedzieli inni: intruzi próbujący wielu loginów mogą zagracać twoje pliki dziennika (nawet jeśli ataki słownikowe z jednego adresu IP można zablokować za pomocą fail2ban);
  • SSH potrzebuje kryptografii klucza publicznego do wymiany tajnych kluczy w celu utworzenia bezpiecznego tunelu (jest to kosztowna operacja, która w normalnych warunkach nie musi być wykonywana bardzo często); powtarzające się połączenia SSH mogą marnować moc procesora .

Uwaga: Nie mówię, że powinieneś zmienić port serwera. Właśnie opisuję uzasadnione powody (IMO) zmiany numeru portu.

Jeśli to zrobisz, myślę, że musisz wyjaśnić każdemu innemu administratorowi lub użytkownikowi, że nie powinno to być uważane za funkcję bezpieczeństwa, a użyty numer portu nie jest nawet tajemnicą, i że opisuje to jako funkcję bezpieczeństwa zapewniające rzeczywiste bezpieczeństwo nie jest uważane za zachowanie dopuszczalne.

ciekawy
źródło
Pliki dziennika można łatwo uporządkować za pomocą odpowiednich filtrów. Jeśli mówisz o wydajności serwera z powodu zmniejszonej liczby logów, to nie mówimy już o bezpieczeństwie. Wydajność to zupełnie inny temat.
Pacerier
Nie, gdy komputer staje się bezużyteczny z powodu nadmiernego użycia dysku.
ciekawy
Tak, to jest problem z wydajnością. Wydajność jest również zdecydowanie ważna, ale ten konkretny wątek dotyczy wyłącznie bezpieczeństwa. (Na potrzeby tego wątku wyobraź sobie, że masz rozmiar Google, a Google naprawdę chce tych danych do analizy i / lub sprzedaży).
Pacerier
1

Widzę jedną hipotetyczną sytuację, w której potencjalna korzyść z bezpieczeństwa wynikałaby z uruchomienia twojego sshd na alternatywnym porcie. Tak byłoby w przypadku, gdy w uruchomionym oprogramowaniu sshd zostanie wykryta trywialnie wykorzystana luka w zabezpieczeniach. W takim scenariuszu uruchomienie sshd na alternatywnym porcie może dać ci dodatkowy czas, w którym nie musisz być losowym celem przejazdu.

Sam uruchamiam sshd na alternatywnym porcie na moich prywatnych komputerach, ale to głównie dla wygody, aby utrzymać bałagan w /var/log/auth.log. W systemie z wieloma użytkownikami naprawdę nie uważam przedstawionej powyżej małej hipotetycznej korzyści bezpieczeństwa za wystarczający powód dodatkowych kłopotów spowodowanych brakiem sshd w standardowej części.

andol
źródło
Scenariusz byłby ważny tylko wtedy, gdy wszyscy administratorzy absolutnie nie skorzystają z tego „dodatkowego czasu” na pójście na lunch itp.
Pacerier
1

To nieznacznie zwiększa bezpieczeństwo. Atakujący, który znalazł otwarty port, musi teraz sprawdzić, co działa na porcie. Nie mając dostępu do twoich plików konfiguracyjnych (jeszcze :-)) nie ma pojęcia, czy port 12345 obsługuje http, sshd, czy jedną z tysiąca innych powszechnych usług, więc muszą wykonać dodatkową pracę, aby dowiedzieć się, co działa, zanim będą mogli poważnie się zorientować. zaatakuj to.

Również, jak wskazał inny plakat, podczas gdy próby zalogowania się do portu 22, mogą być nieporadnymi dzieciakami skryptowymi, trojanami zombie, a nawet prawdziwymi użytkownikami, którzy błędnie wpisali adres IP. Próba zalogowania się do portu 12345 jest prawie na pewno prawdziwym użytkownikiem lub poważnym napastnikiem.

Inną strategią jest posiadanie kilku portów „pułapki na miód”. Ponieważ żaden prawdziwy użytkownik nie wiedziałby o tych numerach portów, każdą próbę połączenia należy uznać za złośliwą, a użytkownik może automatycznie zablokować / zgłosić naruszający adres IP.

Istnieje szczególny przypadek, w którym użycie innego numeru portu z pewnością zwiększy bezpieczeństwo twojego systemu. Jeśli w sieci działa usługa publiczna, taka jak serwer sieci Web, ale działa także serwer sieciowy tylko do użytku wewnętrznego, można całkowicie zablokować dostęp zewnętrzny, uruchamiając inny numer portu i blokując dostęp zewnętrzny z tego portu.

użytkownik23523
źródło
Wzrost bezpieczeństwa o ~ 0,1% należy porównać z odpowiednim spadkiem bezpieczeństwa , co prawdopodobnie spowoduje całkowitą utratę bezpieczeństwa netto w zależności od przypadku użycia i kontekstu.
Pacerier
0

Nie sam w sobie. Jednak niestosowanie domyślnego portu dla konkretnej aplikacji (powiedzmy SQL Server) zasadniczo zmusi atakującego do przeskanowania portów; zachowanie to może zostać wykryte przez zaporę ogniową lub inne wskaźniki monitorowania, a adres IP atakującego zostanie zablokowany. Ponadto przeciętny „skryptowy dzieciak” będzie bardziej zniechęcany, gdy używane przez niego proste narzędzie lub skrypt poleceń nie znajdzie instancji serwera SQL na twoim komputerze (ponieważ narzędzie sprawdza tylko domyślny port).

KeithS
źródło