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

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?

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.

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.

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.

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ął.

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?

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.

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.

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.

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.

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.

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).