Pytanie:
Czy korzystanie z niejasnych numerów portów zwiększa bezpieczeństwo?
William Rosenbloom
2018-07-17 05:56:42 UTC
view on stackexchange narkive permalink

Niedawno podjąłem pracę w małej firmie, w której CTO woli hostować usługi SSH na mało znanych, wysoko numerowanych portach na naszych serwerach, zamiast na dobrze znanym porcie 22. Jego uzasadnieniem jest to, że „zapobiega to 99% ataków kiddy skryptowych ”. Jestem ciekawy, czy jest to uważane za złą praktykę.

Intuicyjnie wydaje się to rozsądne. Ale obaj jesteśmy w dużej mierze samoukami i nie podoba mi się pomysł improwizowania naszych własnych procedur bezpieczeństwa zamiast przestrzegania dobrze ugruntowanej konwencji. Wiem, że ogólnie schematy i protokoły kryptograficzne są starannie opracowywane przez zespoły ekspertów i że każdy szczegół ma na celu ochronę przed jakimś rodzajem ataku, bez względu na to, jak nieistotne może się to wydawać. Martwię się niezamierzonymi konsekwencjami odstąpienia od tych zaleceń.

Ale wydaje się, że mój kolega ma dowody po swojej stronie. Był w stanie wykazać, że każdego dnia otrzymujemy dziesiątki ataków, które próbują wykorzystać port 22 i po prostu idą dalej. Wiem, że generalnie powinniśmy unikać bezpieczeństwa poprzez zaciemnienie, ale odejście od tego wspólnego celu naprawdę wydaje się udaremniać większość ataków .

Czy to dobrze ćwiczyć czy nie? Czy powinniśmy używać dobrze znanych portów?

ADDENDUM

Nie polegamy tylko na mało znanym porcie. Wprowadziliśmy wiele innych środków bezpieczeństwa, w tym obowiązkowe klucze sprzętowe. Wyjaśnię jeszcze raz moje pytanie.

Czy jest jakiś powód, dla którego w szczególności port 22 został wybrany dla SSH? Czy jest coś niebezpiecznego w używaniu innych portów?

Nie ma czegoś takiego jak bezpieczeństwo przez zapomnienie.Jest tylko niejasność.Ta zasada została ustanowiona dziesiątki lat temu.
Moim zdaniem mniej śmieci w plikach dziennika jest funkcją bezpieczeństwa, ponieważ oznacza to, że możesz bardziej skoncentrować się na rzeczywistych problemach.
Jeśli chcesz przyzwoitego zabezpieczenia przez zaciemnienie (:)), powinieneś użyć funkcji port knocking zamiast prostych niestandardowych portów.Pukania do portów nie można pokonać skanowaniem.Jedynym sposobem, aby temu przeciwdziałać, jest przyzwoita analiza ruchu, która jest o wiele trudniejsza.
Bezpieczeństwo dzięki niejasności nie jest z natury złe, poleganie wyłącznie na nim jest.Niewidzialność może zapewnić znikome korzyści, które nie mogą zastąpić prawdziwego bezpieczeństwa, ale można je dodatkowo wykorzystać.Wadą niejasności jest to, że zwykle powoduje to niedogodności dla autoryzowanych użytkowników (którzy muszą pamiętać o odstępstwie od normy), a bezpieczeństwo polega ogólnie na ustaleniu równowagi między ograniczaniem nieautoryzowanych użytkowników bez zbytniego utrudniania autoryzowanym użytkownikom.
Zależy to całkowicie od wektora ataku, o którym myślisz.Jeśli chcesz uniknąć ludzi od niechcenia skanujących sieć w poszukiwaniu portu 22, to oczywiście, ale jeśli chcesz się bronić przed kimś atakującym twój host, to nie trochę.
Dlaczego port 22 jest dostępny dla publicznego Internetu?
Możliwy duplikat [The valid role of obscurity] (https://security.stackexchange.com/questions/2430/the-valid-role-of-obscurity)
Mam serwer ssh na raspberry pi i jest dostępny z internetu.Kiedy uruchomiłem ssh na porcie 22, partycja dziennika 10 MB ramdysku zapełniła się w ciągu kilku godzin - wszystko z powodu rejestrowania prób logowania.Po przeniesieniu ssh do wysokiego portu nie miałem ani jednej próby nieautoryzowanego dostępu od 6 miesięcy.Dla mnie to korzyść.
Jeśli zainstalowałeś nowy SSH i tylko monitorowałeś logi w ciągu pierwszej godziny, policzyłeś setki, jeśli nie tysiące prób!Tak na marginesie, to właśnie zachęciło mnie do sporządzenia honeypot tylko po to, by się zabawić!
Nie wiem, czy podpiszesz swoje pytanie prawdziwym imieniem i nazwiskiem, ale jeśli to zrobisz, lub jeśli Twoją tożsamość można ustalić na podstawie Twoich postów, być może ujawniasz zbyt wiele.
W tym przypadku niedogodności dla autoryzowanych użytkowników będą prawdopodobnie dość niskie, ponieważ mogą oni ogólnie skonfigurować swoje oprogramowanie SSH (nawet SSH z wiersza poleceń ma zwykle coś takiego jak `~ / .ssh / config`, aby przypisać krótką nazwę do skomplikowanego połączenia), aby połączyć się z jakimś dziwnym portem za pierwszym razem i nie musieć zapamiętywać portu w przyszłości.
Dziesięć odpowiedzi:
Steve Sether
2018-07-17 10:37:11 UTC
view on stackexchange narkive permalink

Czy korzystanie z niejasnych numerów portów poprawia bezpieczeństwo?

Jeśli już używasz haseł o dużej entropii lub uwierzytelniania za pomocą klucza publicznego, odpowiedź brzmi „nie bardzo”. Zwykle po prostu pozbywasz się hałasu w dziennikach.

Martwię się niezamierzonymi konsekwencjami odstąpienia od tych zaleceń.

To zależy od wybranego portu. W Linuksie domyślnie wszystkie porty poniżej 1024 wymagają uprawnień administratora, aby nasłuchiwać na nich. Jeśli używasz portu powyżej 1024, każde konto użytkownika może nasłuchiwać na nim, o ile nie ma jeszcze procesu nasłuchującego.

Dlaczego to ma znaczenie? Załóżmy, że wybrałeś ustawienie ssh tak, aby wiązało się z portem 20 000 . Gdyby ktoś mógł zatrzymać proces SSH na serwerze (powiedzmy, że w jakiś sposób znalazł sposób na zawieszenie tego procesu) i miał lokalny dostęp do tego serwera, mógłby następnie uruchomić własny serwer SSH na porcie 20 000 przed ponownym uruchomieniem usługi. Każdy logujący się wtedy logowałby się na serwer SSH złych facetów.

To nie jest taka wielka sprawa, jak kiedyś, ponieważ obecnie tylko zaufani pracownicy IT mają dostęp do logowania serwery. Mimo to ma potencjał do eskalacji przywilejów i innych nieprzyjemności, jeśli atakujący zdobędzie przyczółek na Twoim serwerze.

Poza tym, że jest poniżej 1024, nie ma nic specjalnego w liczbie 22. W dużej mierze została wybrana, ponieważ SSH zastąpił telnet na porcie 23 , a 21 był już zajęty przez FTP. Jeśli wybierzesz port poniżej 1024 , port nie ma znaczenia.

Czy to dobra praktyka, czy nie? Czy powinniśmy używać dobrze znanych portów?

Nie powiedziałbym, żebym to polecał. Nie odradzałbym też tego. Jak powiedziałem, pozwala uniknąć dużego szumu w plikach dziennika, ale korzyści są w dużej mierze ograniczone do tego.

Każdy zainteresowany historią o SSH może ją znaleźć pod adresem: https://www.ssh.com/ssh/port

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/80438/discussion-on-answer-by-steve-sether-does-it-improve-security-to-use-obscure-por).
Nie.Każdy, kto próbowałby zalogować się do tego złego serwera, spotkałby się z dużym ostrzeżeniem mówiącym, że klucz hosta się zmienił (przyznano klientom _można_ cofnąć się, edytować ich pliki znane_hosts, aby usunąć taki wpis, połączyć się ponownie, zaakceptować nieznany kluczna inny serwer należący do atakującego, na którym brakuje nawet plików, które mieli w domu).Zauważ również, że przekierowanie może być wykonane przez iptables, więc sshd w rzeczywistości nasłuchuje na 22 (nieosiągalny z zewnątrz), a prawdziwy port 20 000 jest przez niego zasłonięty).
@ Ángel Chociaż jest to poprawne, nadal zapewniałoby to możliwości komuś z luką w arbitralnym odczycie lub atakiem kanału bocznego, który umożliwia dostęp do kluczy hosta (co nie jest nieznacznym ryzykiem).Ponadto ułatwia ataki socjotechniczne i umożliwia wykorzystanie klienta.Masz jednak rację co do używania iptables do przekierowywania portów, co byłoby dobrym pomysłem, jeśli chcesz bezpiecznie używać wysokiego portu.
Tom
2018-07-17 17:21:08 UTC
view on stackexchange narkive permalink

Tak. Prawdziwe pytanie brzmi: o ile?

Dlaczego tak się dzieje? Masz już podstawowe zabezpieczenia, więc codzienne ataki botów Cię nie martwią. Ale jutro może być dzień zerowy, a atakujący wiedzą, że nie potrwa długo, aż łatka zostanie wydana, więc próbują go użyć i nie będą zawracać sobie głowy czymś skomplikowanym - po prostu uderzą w jak najwięcej maszyn na standardowy port. Każdy rodzaj teoretycznego robaka SSH również użyłby tej strategii. Byłbyś przed tym chroniony.

Ile dodatkowego bezpieczeństwa daje ci to? Chroni przed tym i może 2-3 innymi konkretnymi scenariuszami. W najlepszym przypadku doda to kilka minut do każdego ukierunkowanego ataku ze strony każdego, kto nie jest totalnym idiotą. Nie ma to żadnego wpływu na scenariusze, przed którymi jesteś już odpowiednio chroniony.

Włączając te liczby do swojej ulubionej metody analizy ryzyka, powinieneś wymyślić coś stosunkowo małego. Z drugiej strony masz dodatkowy wysiłek związany z ustawieniem niestandardowego numeru portu, udokumentowaniem go, być może pominięciem go podczas rozwiązywania problemów i stratą czasu itp.

Domyślam się, że prawie zerwałbyś z analizą. Lub innymi słowy: tak, poprawia bezpieczeństwo, ale nie jest to warte zachodu, ponieważ poprawa jest bardzo niewielka.

* „jutro może nastąpić zero-day i [atakujący] uderzą w jak najwięcej maszyn na standardowym porcie” * Dobra uwaga, której nie widziałem w innych odpowiedziach!
Twoje pierwsze zdanie jest błędne.Może „poprawić” bezpieczeństwo tylko wtedy, gdy właściwa ochrona (np. * Zapora sieciowa blokująca port 22 przed ruchem internetowym * lub wiele zapór sieciowych od różnych dostawców, jeśli chcesz uzyskać dogłębną ochronę, np. Zapora ogniowa na urządzeniu, która umożliwia publiczny dostęp do Internetusieć, a następnie zapora ogniowa na poziomie komputera).Jeśli go nie ma, obrońca nadal przegrywa z nieco bardziej wyrafinowanymi atakami, które zawracają sobie głowę sprawdzaniem innych portów.Przegrana z 1% atakujących wciąż przegrywa.
@jpmc26, nie rozumiesz bezpieczeństwa i uważasz, że jest to właściwość binarna.Tak nie jest.Jestem również ciekawy, dlaczego muszę blokować zamknięty port za pomocą dwóch zapór ogniowych i dlaczego to zapewnia mi dodatkowe bezpieczeństwo.
@Tom Możesz ponownie przeczytać komentarz, ponieważ odpowiedziałem na to.Twoja odpowiedź sugeruje, że niestandardowy port pomaga chronić się przed lukami zero-day.Jeśli martwisz się o te w swojej zaporze, możesz użyć wielu zapór, aby uzyskać lepszą ochronę w głębi niż niestandardowy port na wypadek, gdyby któryś z nich zawiódł.Przy takiej konfiguracji niestandardowy port nic nie daje, a ta konfiguracja chroni przed * większą * liczbą scenariuszy niż niestandardowy port (jak ktoś, kto zadaje sobie trud skanowania wszystkich portów).Niepewność jest w najlepszym razie kiepska.Czy na pewno * to ja * nie rozumiem bezpieczeństwa?
@jpmc26, jakie znaczenie w tym pytaniu miałby dzień 0 * w zaporze *?Mówiłem wyraźnie o dniu 0 * w sshd * i jasno opisałem scenariusz.Oboje zgadzamy się, że użycie niestandardowego portu zapewnia co najwyżej ** niewielki ** wzrost bezpieczeństwa, ale są ** scenariusze, w których ma to znaczenie.
@Tom Dzień zerowy na SSH nie ma znaczenia, jeśli atakujący nie może nawet połączyć się z SSH.W przypadku zapory ogniowej do ataku nawet na SSH wymagana jest luka (np. Dzień zerowy) w samej zaporze.Jedyne scenariusze, w których te metody zaciemniania mają znaczenie, to te, w których nie są stosowane odpowiednie środki bezpieczeństwa, aw takich scenariuszach * niewielki * wzrost wysiłku atakującego je pokonuje.Głupie jest ryzykowanie, że żaden napastnik jej nie wyda.Używaj środków bezpieczeństwa, które sprawiają, że zaciemnienie jest nieistotne, jeśli faktycznie chcesz chronić się przed zagrożeniami lub nie jesteś w ogóle bezpieczny.
Wiem, jak działa firewall.Zakładałem, że pytający nie jest kompletnym idiotą i ma otwarty SSH, ponieważ potrzebuje go, aby był dostępny.Twoja druga część przedstawia typowe błędne przekonanie dotyczące bezpieczeństwa - że Twoja ochrona musi opierać się ** każdemu ** napastnikowi.To jest złe.Jeśli muszę wyjaśnić dlaczego, otwórz nowe pytanie, które wykracza poza limit znaków w komentarzach.
@Tom Muszą stawić opór każdemu napastnikowi w modelach zagrożeń, które rozważasz.Oczywiście model zagrożenia nie obejmuje tylko atakujących, którzy nie sprawdzają innych portów;dowodzi tego OP, ponieważ twierdzą, że tylko * 99% * atakujących zostałoby udaremnionych przez ten mechanizm.Atakujący są bardzo sprytni.Zakładanie, że nie odkryją informacji, które są „ukryte” w zwykłej witrynie, jest po prostu głupie, jak pokazuje nam historia.
Jeśli udaremnisz 99% atakujących, oznacza to, że zostaniesz zhakowany raz na 10 lat zamiast 10 razy w roku.Jeśli uważasz, że to nie jest różnica, nie mamy nic do omówienia.
Z pewnością skrypty dzieciaki uruchamiają skanery portów, szukając ulubionego portu swojego ulubionego. Posiadanie innego portu oznacza 99,9% dzieciaków skryptów i samodzielnej dystrybucji. 0 dni nic nie znajduje, a 0,1% atak na cel nie jest powstrzymanymało.
„Jeśli udaremnisz 99% atakujących, oznacza to, że zostaniesz zhakowany raz na 10 lat zamiast 10 razy w roku. Jeśli uważasz, że to nie jest różnica, nie mamy nic do omówienia”.To fałszywie zakłada, że porównujemy niejasne porty z brakiem ochrony.To wcale nie jest to, co sugerowałem.Powiedziałem, że mało znany port nic nie robi, jeśli masz odpowiednie zabezpieczenia i nie ma powodu, aby ich unikać.Jeśli zostaniesz zhakowany raz na 10 lat, poniesiesz porażkę.
@jpmc26 - mijamy się.Odniosłem się już do wszystkiego, co powiedziałeś i mówisz dalej.Sprawa, którą teraz poruszyłeś, odniosłem się w moim oryginalnym poście.Naprawdę nie mam nic do dodania.
vidarlo
2018-07-17 09:35:19 UTC
view on stackexchange narkive permalink

Nie, to nie poprawi bezpieczeństwa. Może to zmniejszyć bałagan w dziennikach, ponieważ zautomatyzowane ataki będą próbować tylko portów domyślnych, np. ssh. Ale port nadal będzie wyświetlany jako SSH podczas skanowania portu i shodan.io.

Te automatyczne ataki zwykle mają na celu nisko wiszące owoce, ze standardowymi nazwami użytkowników, takimi jak root, smith i tak dalej, oraz słabe hasła. Jeśli im się to uda, masz problem przede wszystkim.

Jeśli skonfigurujesz ssh tak, aby zezwalał tylko na uwierzytelnianie klucza, nie zezwalał na logowanie rootem i używał rozsądnych haseł, użyj fail2ban lub podobnego mechanizmu do blokowania przestępców, nie są prawdziwym zagrożeniem.

Używam fail2ban skonfigurowanego do tymczasowego blokowania na pięć minut po trzech nieudanych próbach i na tydzień po 3 * 5 nieudanych próbach. Zmniejsza to bałagan w dziennikach i blokuje jakikolwiek rzeczywisty postęp w ataku brutalnej siły.

W przypadku atakującego ukierunkowanego nie ma znaczenia, na którym porcie nasłuchują. Ma to znaczenie tylko w przypadku ataków automatycznych, które moim zdaniem stanowią znikome ryzyko.

Czy nie uważa się, że rzadziej atakowane jest ulepszenie zabezpieczeń?Ponieważ zgadzam się, przypadkowe trolle zazwyczaj są powstrzymywane przez nawet podstawowe środki ostrożności.Ale czy każdy atak nie wiąże się z niewielkim ryzykiem włamania?Nawet jeśli ryzyko jest tak nieprawdopodobne, jak prawidłowe odgadnięcie klucza RSA?
Moim zdaniem nie ma realnego ryzyka w przypadku brutalnej siły przeciwko RSA.I jeszcze nie zauważyłem żadnych automatycznych ataków próbujących to zrobić;próbują uwierzytelnić hasło.W przypadku prawdziwego, ukierunkowanego ataku, który wykona podstawową pracę, aby znaleźć prawidłowe nazwy użytkownika i tak dalej, zmiana portu nie pomoże.
@WilliamRosenbloom, większość zautomatyzowanych ataków wiąże się z zerowym ryzykiem naruszenia.Weźmy pod uwagę faceta, który przez ostatni rok próbował siłą root uzyskać dostęp do mojego serwera: nawet gdyby miał hasło, klucz prywatny i pomoc najlepszych hakerów na świecie, nie ma żadnego ryzyka, że się do niego dostanie. Mój serwer jestskonfigurowany do odrzucania wszystkich żądań logowania od roota.
@WilliamRosenbloom Z wyjątkiem tego, że nie zmniejszy na stałe ataków.Niektóre botnety mogą nigdy się nie dowiedzieć, ale istnieją sprytne, które dowiedzą się dzięki skanowaniu portów lub inspekcji ruchu.Kiedy to się stanie, wrócisz do miejsca, w którym zacząłeś.Ponadto nie robi dosłownie nic przeciwko poważnym atakom ukierunkowanym, każdy wprawny napastnik szybko zorientuje się, na jakim porcie się znajduje.
Zgoda.Jeśli twoje uwierzytelnianie ssh jest solidne, to najbardziej niebezpiecznym atakiem na ciebie jest jakieś zaawansowane trwałe zagrożenie (APT).Cyberprzestępcy APT nie dadzą się zwieść bezpieczeństwu poprzez ukrywanie słuchaczy ssh na innych portach.Jeśli jesteś zmuszony do reagowania na incydent pod presją, będziesz szczęśliwy, że masz standardowe rzeczy.
fail2ban może pomóc, ale wymaga Pythona, zasobnika zasobów na niektórych urządzeniach.Poza tym, chociaż trzeba zachować równowagę, uważam, że nie jest dobrą praktyką w zakresie bezpieczeństwa wierzyć, że zawsze będzie zerowe ryzyko ataków siłowych i jednocześnie być wrażliwym na dowody nieszkodliwych ataków w dziennikach zabezpieczeń.Stwarza okazję bardziej niebezpiecznemu napastnikowi do działania pod przykrywką hałasu i samozadowolenia.Wysoki port (na razie) maksymalizuje SNR;ataki na nią wskazują na bardziej zdeterminowanego napastnika i zwracają odpowiednią uwagę.
Następnie uzyskaj lepszą przeglądarkę dziennika, która może odfiltrować nieprawidłowe próby uwierzytelnienia nazwy użytkownika, próby rootowania i tak dalej, a Twój współczynnik Signal-Noise-Ratio wróci do prawdziwych atakujących próbujących uzyskać prawidłowe konta użytkowników.
Sayan
2018-07-17 06:27:06 UTC
view on stackexchange narkive permalink

Zmiana domyślnego portu może uchronić Cię przed skanowaniem portów i skryptami dzieciaków, ale możesz nie być w stanie wytrzymać ataku ukierunkowanego, w którym osoba atakująca mogłaby zidentyfikować działające usługi nieistotne dla portów.

Jeśli chcesz po prostu uciekaj od dzieciaków ze skryptów, może to być pomocne, ale możesz nie być w stanie zabezpieczyć się przed pozostałymi atakami z wyprzedzeniem.

Moim zaleceniem jest użycie domyślnego portu (może zmniejszyć obciążenie administracyjne) i wdrożenie wielopłaszczyznowych zabezpieczeń w celu złagodzenia ataków.

Na przykład przy używanym domyślnym porcie wdrażanie uwierzytelniania opartego na certyfikatach za pomocą protokołu SSH jest dozwolone tylko w niektórych zaufanych źródłach.

Nie polegamy na niejasności.Mamy wiele innych środków bezpieczeństwa, w tym [sprzętowe klucze uwierzytelniające] (https://www.yubico.com/products/yubikey-hardware/).Niejasne porty to tylko dodatkowa warstwa oprócz konwencjonalnych zabezpieczeń.** Wiedząc o tym, czy nadal zalecałbyś używanie domyślnego portu 22?Czy jest jakiś powód inny niż ogólne koszty administracyjne? **
@WilliamRosenbloom Biorąc to wszystko pod uwagę, wyraźnie już bronisz się przed podstawowymi atakami.Każdy, kto jest w stanie ominąć twoje sprzętowe klucze uwierzytelniające, również byłby w stanie znaleźć ten alternatywny port ... więc myślę, że post Sayana nadal jest aktualny: „użyj domyślnego portu i wdróż [wiele warstw] zabezpieczeń”, tak jak to zrobiłeś.
Jeśli używasz kluczy sprzętowych, używanie niestandardowych portów to tylko teatr bezpieczeństwa.Osoba atakująca, która ma ** jakąkolwiek ** szansę na złamanie klucza sprzętowego, i tak zidentyfikuje Twój prawdziwy port ssh w mgnieniu oka.W rzeczywistości osoba atakująca na znacznie niższym poziomie mogłaby to łatwo zrobić.
SSLTrust
2018-07-17 06:21:23 UTC
view on stackexchange narkive permalink

Powiedziałbym, że tak, używaj niestandardowych numerów portów, ponieważ odfiltruje to WIELE automatycznych botów. ale nie polegaj na tym, ponieważ wiele botów, które zauważyłem, przeskanuje sieć / host w poszukiwaniu otwartych portów i wypróbuje je.

Najlepszą rzeczą jest zaimplementowanie dobrych zabezpieczeń na porcie SSH . wyłącz logowanie roota, umieszczaj adresy IP na białej liście, jeśli możesz, nie używaj haseł do logowania (używaj kluczy), włącz także powiadomienia o wszelkich logowaniach. I skonfiguruj firewall, to ważne.

Pozwól nam [kontynuować tę dyskusję na czacie] (https://chat.stackexchange.com/rooms/80477/discussion-between-forest-and-patrick-mevzek).
user6858980
2018-07-17 16:24:22 UTC
view on stackexchange narkive permalink

Zasłanianie portów na tak dużych numerach zatrzymuje tylko proste boty, które będą szukać dobrze znanych portów. Skryptowe dzieciaki i zdeterminowani hakerzy mogą po prostu przeskanować pozostałe porty w celu znalezienia usługi, więc zatrzymujesz tylko trochę szumu dziennika.

To naprawdę nie ma znaczenia, jeśli chodzi o konwencję nie nasłuchiwania na standardzie port dla tej usługi. Twórcy tej usługi dają ci możliwość uruchomienia jej na dowolnym innym porcie, a każdy program, który może z nią współdziałać, będzie miał możliwość określenia portu, z którym chcesz rozmawiać.

Zgadzam się z innymi pisze tutaj, że wrażliwe porty, takie jak SSH, powinny być trzymane w uprzywilejowanej przestrzeni portu poniżej 1024.

Lepszym sposobem na ukrycie SSH, który faktycznie działa, jest zapukanie portu. Obejmuje to zamknięcie portu w iptables, aż sekwencja portów zostanie „zapukana”, co spowoduje otwarcie żądanego portu.

Np. Możesz wysłać pakiet pod numer 8000 4545 28882 7878. Po wybraniu żądanej sekwencji wprowadzone iptables odblokuje żądany port. To naprawdę powstrzymuje większość dzieciaków skryptów i hakerów, ponieważ żaden port nie jest reklamowany. Ale to nie kończy się na atakach typu replay, ale w tym momencie masz większe problemy, o które musisz się martwić.

https://en.wikipedia.org/wiki/Port_knocking.

Naprawdę powinieneś używać TCPWrappers i zezwalać tylko znanym adresom IP i zakresom sieci na dostęp do portów, takich jak SSH. Czy musisz pozwolić adresom IP z Chin na dostęp do SSH? A może programiści będą potrzebować dostępu tylko z biurowej sieci LAN? Jeśli pracują zdalnie, ustaw ich VPN w sieci LAN

pukanie do portu to fajny pomysł na bezpieczeństwo, ale ma absolutnie straszną użyteczność.
@Tom, chyba że napiszesz skrypt, który zajmie się tym za Ciebie ... Użyteczność dla zdalnego administratora nie jest tak naprawdę wielkim problemem.
@schroeder zakładasz, że zawsze robisz swoje czynności administracyjne z tego samego komputera, na którym masz pod ręką swój sprytny skrypt.W takim przypadku nie potrzebujesz pukania do portów, uwierzytelnianie oparte na kluczach również sprawi, że ataki brute-force będą bezcelowe.
@tom tak, zakładam, że.Jeśli administratorzy logują się z nieznanych lub niekontrolowanych maszyn, masz inny problem.Twój komentarz na temat opartego na kluczach jest również mylący: uwierzytelnianie oparte na kluczach jest okropne dla użyteczności.Myślę, że być może będziesz musiał rozszerzyć to, co masz na myśli w swoim oryginalnym komentarzu i jakie założenia przyjmujesz jako podstawę.
@schroeder - masz rację, że uwierzytelnianie oparte na kluczach nie jest dużo lepsze pod względem użyteczności, ale przynajmniej jest to standardowa procedura. Z mojego doświadczenia wynika, że twoje założenie będzie poprawne w 99% przypadków, a błędne w tym jednym przypadku, gdy naprawdę musisz się zalogować, ale jesteś gdzieś bez notebooka.Wystarczająco często blokowałem sobie dostęp do maszyn, aby wiedzieć, że zawsze musisz mieć przynajmniej jeden sposób, który nie wymaga żadnego specjalnego oprogramowania ani konfiguracji.
@Tom wyjaśni, dlaczego uważasz, że to urocze zabezpieczenie?Port jest odgrodzony, dopóki nie odblokujesz go tą metodą, wtedy nadal masz wszystkie istniejące środki bezpieczeństwa.Jeśli nie reklamujesz swojego portu, unikniesz większości skanowań sieci. Jeśli usługa za ukrytym portem stanie się podatna na ataki, da ci to również dużo czasu na przejście, zanim zautomatyzowane hacki zaczną napływać. Pomyśl, jak to mogło powstrzymać szok shellshockrozprzestrzenia się tak szybko.Tak, użyteczność spada, teraz muszę wysłać 3 pakiety zanim się zaloguję, taka trudność.
@user6858980 Nazwałem to „słodkie”, ponieważ jest to jedna z rzeczy, które ktoś mówi ci na konferencji, a ty mówisz „teraz to niezły pomysł”, dopóki nie przemyślisz wszystkich konsekwencji.I tak, wysłanie 3 pakietów może być piekielnym zadaniem, jeśli jesteś, powiedzmy, w kafejce internetowej.Zrestartowałem zepsute serwery przy użyciu Palm Pilota i telefonu GSM (nie 3G, nie 2G, GSM) podczas jazdy pociągiem.Rozwiązałem problem na iPadzie.Powodzenia w załatwianiu sprawy w porcie, gdy jesteś w sytuacji awaryjnej bez zwykłego sprzętu.
więc jakie są konsekwencje, które nie sprawiają, że jest to praktyczne?Mówisz, że jest problem bez podania jakichkolwiek informacji.Pojęcie, że nie możesz wysłać trzech pakietów przez GSM w pociągu, jest nieistotne, jeśli masz wystarczająco stabilne połączenie sieciowe, aby utrzymać połączenie ssh, masz wystarczająco dużo do zrobienia dla x w $ PORT1 $ PORT2 $ PORT3;do nmap -Pn --host_timeout 201 --max-retries 0 -p $ SERVER_IP;Gotowe;ssh użytkownik @ $ SERVER_IP.Lub trzy telnety i ssh.Powiedz mi, jak można wykorzystać podatną na ataki usługę lub brutalnie wymusić coś, co jest zaporą ogniową i nie jest reklamowane?
Yury Schkatula
2018-07-17 20:51:10 UTC
view on stackexchange narkive permalink

Jak wspominali inni, migracja do niestandardowego portu nie jest rozwiązaniem zabezpieczającym, ponieważ odfiltrowuje się tylko ataki naiwny.

Jednocześnie migracja może być znacznie bardziej wartościowa w połączeniu z innymi środki ostrożności. Na przykład umieszczasz honeypot na standardowym porcie (środowisku, które jest fizycznie odizolowane od reszty systemu, ale wygląda jak legalny element dla atakującego). Następnie, jeśli zobaczysz, że ktoś włamał się do honeypota, prawdopodobnie jest to haker, więc możesz go automatycznie zablokować.

I na pewno nie powinieneś używać przestarzałych wersji oprogramowania ze znanymi lukami, niezależnie od numer portu, którego mają słuchać.

Nie uruchamiaj honeypota na serwerze produkcyjnym
@AndrolGenhald Pomysł mi się podoba.Atakujący spróbuje 22 przed jakimikolwiek alternatywnymi portami, więc jeśli widzisz tam tyle, co TCP SYN, możesz zablokować adres IP przed dostępem do dowolnego portu (więc host będzie wyglądał na martwy dla atakującego).Lub możesz przekierować ruch na porcie 22 do serwera honeypot w innym miejscu.Zgadzam się, że honeypot o wysokiej interakcji na prodzie zdecydowanie nie jest dobrym pomysłem.
@AndrolGenhald, nie wystawia nagiego serwera produkcyjnego na świat zewnętrzny.Wtedy posiadanie honeypota dostępnego pod tym samym adresem IP co serwer produkcyjny może być po prostu konfiguracją routingu.
@Luc Tak, posiadanie czegoś, co nasłuchuje i loguje się na porcie 22 może być przydatne lub przekierowuje to gdzie indziej, ale odpowiedź nic z tego nie wyjaśnia.YurySchkatula Może powinieneś to dodać do swojej odpowiedzi?
@Luc Brzmi jak dobry sposób na zablokowanie administratorom systemu, gdy dostaną nowy komputer i zapomną zmienić port przy pierwszej próbie połączenia.
@jpmc26 Dobrzy administratorzy używają plików `.ssh / config` ;-).Ale co ważniejsze, dobre zabezpieczenia rzadko mają wpływ na użyteczność.To, gdzie wyznaczyć granicę między użytecznością a bezpieczeństwem, zależy od sytuacji.Być może za pierwszym razem baner może ich ostrzec przed zakazem?Znowu zależy to od sytuacji ...
@Luc Istnieją jednak lepsze alternatywy, takie jak użycie białej listy adresów IP w pierwszej kolejności (przez zaporę ogniową) i po prostu blokowanie ruchu zewnętrznego na porcie 22.
jpmc26
2018-07-18 08:42:33 UTC
view on stackexchange narkive permalink

Nie, nie lub, jeśli chcę być bardziej precyzyjny, to zła ochrona przed zagrożeniem .

Cofnij się o krok: jakiego zagrożenia chcemy chronić przed? Zagrożeniem, przed którym staramy się chronić, jest każda osoba w publicznym internecie, która może ominąć normalny mechanizm uwierzytelniania. To właśnie próbują zrobić te „dzieciaki od skryptów”: uzyskać dostęp do serwera za pomocą SSH, nawet jeśli nie mają autoryzacji. W szczególności twój przełożony chce uniemożliwić tym atakującym nawet rozpoczęcie ustanawiania połączenia SSH.

Jaka jest standardowa technologia zapobiegająca nawiązywaniu połączeń sieciowych? Zapora. Standardową odpowiedzią na ten problem jest całkowite zablokowanie portu 22 przed ruchem z zewnątrz. Większy problem polega na tym, że SSH jest w ogóle dostępne dla publicznego internetu, a zapora całkowicie to rozwiązuje, podczas gdy niejasny port tylko nieznacznie go ukrywa i właściwie nie uniemożliwia połączeń. Jeśli wymagany jest dostęp zewnętrzny, standardową odpowiedzią na zezwolenie na autoryzowany dostęp jest połączenie VPN do sieci. Zablokowałoby to zarówno dzieciaki skryptów , jak i osoby atakujące wiedzę, które mogłyby dowiedzieć się, jak znaleźć port, którego faktycznie używasz.

Jeśli stracisz do 1% atakujących, nadal przegrywasz . Potrzebujesz zabezpieczeń, które działają przeciwko 100% napastników. Jeśli zamiast tego skutecznie blokujesz 100% atakujących (do tej pory), musisz mieć solidniejsze zabezpieczenia. Te inne zabezpieczenia sprawiają, że niejasny port jest nieistotny. a jeśli tak jest (miejmy nadzieję), całe korzystanie z innego portu powoduje dezorientację ludzi, którzy są mniej zaznajomieni z rzeczywistymi praktykami bezpieczeństwa, takimi jak ty, i prawdopodobnie , marnuj czas ludzi próbujących uzyskać legalny dostęp, gdy próbują się połączyć (nowy system nie jest skonfigurowany i trzeba zapytać kogoś o właściwy port, administrator zapomniał powiedzieć osobie o niestandardowym porcie i osoba musi im ponownie przeszkadzać, aby zdiagnozować problem itp.).

Właśnie dlatego narzekamy na „bezpieczeństwo poprzez zaciemnienie” i zasadę Kerckhoffsa. Powinniśmy unikać rozpraszania się praktykami, które w rzeczywistości nas nie chronią. Powinniśmy zaoszczędzić czas i wysiłek na rzecz ochrony, która faktycznie działa, i unikać fałszywego poczucia „bezpieczeństwa”, które dają nam te metody zaciemniania.

Noir
2018-07-18 17:41:49 UTC
view on stackexchange narkive permalink

Chcę dodać, że ostatecznie bezpieczeństwo to gra o zasoby po obu stronach. Czas jest takim zasobem.

Ten środek marnuje czas napastników, więc nie jest tak źle. Możesz również dowiedzieć się o zasobach atakujących, gdy nadal łączą się z Twoim portem niestandardowym. Być może istnieje większe zainteresowanie, aby skierować się do Ciebie w szczególności.

Jednak jeśli powoduje to znaczne obciążenie dla zadań administracyjnych, możesz poświęcić swój czas gdzie indziej. Jeśli nie, zrób to, ale nie polegaj na tym.

Justin
2018-07-17 09:31:10 UTC
view on stackexchange narkive permalink

Używanie niestandardowych portów w aplikacjach o wysokim stopniu wrażliwości jest BARDZO DOBRE. SSH ma wiele luk w zabezpieczeniach, a 22 to typowy domyślny port do brutalnej siły.

Biorąc to pod uwagę, prawdopodobnie to zależy. Ataki siłowe na serwery DMZ na port 22 są bardzo powszechne, szczególnie w środowisku korporacyjnym. Wiele firm, na przykład w finansach, używa innego domyślnego portu dla ruchu SSH / SFTP w celu prawidłowego przesyłania danych między organizacjami. >

Pomysł w tym przypadku polega bardziej na odfiltrowaniu części szumów (Port 22 Brute Forcing), aby inny ruch na alternatywnym porcie był łatwiejszy do monitorowania. Każdy wystarczająco dobry może znaleźć dowolny otwarty port na serwerze połączonym z Internetem.

Jest to uważane za formę ograniczania lub zmniejszania ryzyka.

Edycja: Powinienem dodać: Kiedy mówię dobrze praktyce, mam na myśli dobre praktyki na urządzeniach z dostępem do Internetu. Wszystko za zaporami sieciowymi jest ogólnie bezpieczne.

[Nie powiedziałbym, że openssh ma ** dużo ** luk w zabezpieczeniach] (https://www.cvedetails.com/product/585/Openbsd-Openssh.html?vendor_id=97).Wiele zgłoszonych problemów może pozwolić uwierzytelnionemu użytkownikowi na uzyskanie uprawnień, ale różni się to od uzyskania dostępu zdalnego napastnika ...
Ukrywanie klucza do drzwi wejściowych pod matą nie jest dobrą praktyką.Tak, to lepsze niż pozostawienie klucza w zamku, ale niewiele lepiej.Lepszym pomysłem jest łagodzenie luk, a nie ich ukrywanie.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...