Bezpiecznie jest używać wysokich numerów portów? (dotyczy: ukrywania usług sieciowych)


9

Mam małą sieć domową i próbuję zrównoważyć potrzebę bezpieczeństwa z wygodą. Najbezpieczniejszym sposobem zabezpieczenia wewnętrznych serwerów sieciowych jest łączenie się tylko za pomocą VPN, ale wydaje się to przesadą w celu ochrony zdalnego interfejsu internetowego rejestratora (na przykład).

Jako kompromis, czy lepiej byłoby używać bardzo dużych numerów portów? (np. pięć cyfr do 65531)

Czytałem, że skanery portów zwykle skanują tylko pierwsze 10 000 portów, więc używanie bardzo wysokich numerów portów jest nieco bezpieczniejsze.

Czy to prawda?

Czy są lepsze sposoby ochrony serwerów sieciowych? (tzn. GUI dla aplikacji)


Nie to nie prawda. Nowoczesne wielordzeniowe procesory (nawet stacjonarne) z dostępem szerokopasmowym mogą skanować wszystkie porty 65535 w kilka sekund. I nawet jeśli atakujący zdecyduje się rozstawić je na dwie sekundy, aby udaremnić bramy DoS, kogo to obchodzi, pozostawiasz swój system dłużej niż jeden dzień, prawda? Starą maksymą jest, jak powiedziano poniżej, że „bezpieczeństwo poprzez zaciemnienie” jest zasadniczo bezużyteczne w świecie cyfrowym.
msanford

Odpowiedzi:


9

Czytałem, że skanery portów zwykle skanują tylko pierwsze 10 000 portów, więc używanie bardzo wysokich numerów portów jest nieco bezpieczniejsze.

Wiele osób w to wierzy. Ja nie.

Może to trochę bardziej bezpieczne, ale niewiele. Porty o niskim numerze są bardziej powszechne, więc niektóre skanery będą tam szukać najpierw.

Gdybym był crackerem, najpierw skanowałbym wysokie porty, aby złapać ludzi, którzy polegają na tej metodzie w zakresie bezpieczeństwa. Ludzie, którzy polegają na bezpieczeństwie przez zaciemnienie, prawdopodobnie słabo rozumieją bezpieczeństwo i częściej zapominają o użyciu innych metod bezpieczeństwa. Dlatego te usługi mogą być bardziej wrażliwe i łatwiejsze do złamania.

Niektóre skanery wykorzystują to przekonanie i zaczynają od góry i idą w dół listy. Inne skany wybiorą losowe porty w całym zakresie, więc wszystkie porty mają jednakową szansę na skanowanie.

Śmiało i przetestuj to sam za pomocą NMAP . Uruchom skanowanie nmap względem portów 1-10 000 i poszukaj serwera HTTP i porównaj to ze skanem, który skanuje wszystkie porty 1-65, xxx. Przekonasz się, że różnica wynosi zwykle 3–10 minut. Jeśli wykonam szczegółowy skan przy użyciu czegoś takiego jak Nessus, różnica wynosi czasami 20–60 minut.

Dobry cracker to cierpliwy cracker. Będą czekać.


1
Zakładając, że wszystkie inne stosowne środki bezpieczeństwa zostały wdrożone, czy lepiej lub gorzej byłoby ukrywać numery portów? Myślę, że byłoby nieco lepiej, gdyby serwer nie był specjalnie ukierunkowany.
wag2639

2
+1 „Dobry cracker to cierpliwy cracker. Będą czekać”.
msanford

@ wag2639 Tak naprawdę nic nie robisz, zmieniając numer portu usługi, ale sprawiając, że skrypciarz znajdzie nieco lepszy skrypt. Wybieranie numeru bloku adresów IP i TAKŻE skanowanie portów każdego portu jest banalne.
msanford

Jeśli haker dąży do określonego celu, może być w stanie czekać 20–60 minut na skanowanie wysokich numerów portów. Jeśli jednak będą próbować przeskanować setki lub tysiące adresów IP w celu znalezienia podatnych systemów, nie będą skanować wysokich portów. Muszą także wiedzieć, że istnieje tam system, zanim zaczną go atakować. Jeśli zapora wykonuje swoją pracę, system jest w zasadzie niewidoczny, dopóki nie natknie się na otwarty port.
user1751825,

3

Używanie nieparzystych numerów portów nie stanowi żadnego zabezpieczenia, chyba że założysz fakt, że pozwala to na uruchamianie aplikacji jako użytkownik inny niż root.

Tego rodzaju rzeczy można uznać za bezpieczeństwo przez zaciemnienie, ale tak naprawdę nie jest to bezpieczeństwo.


Czy są zatem jakieś alternatywy dla korzystania z pełnowymiarowej sieci VPN? Być może jakiś odwrotny serwer proxy z dodatkową ochroną przed zalogowaniem / hasłem? (kałamarnica tego nie robi)
SofaKng,

@sofakng: możesz być zainteresowany opakowaniem SSL, takim jak Stunnel: stunnel.org
Maxwell

3

Możesz także użyć tunelu ssh, jeśli używasz Linuksa na obu końcach:

ssh -f -N -L 9090:localhost:9090 user@remote-host

Na przykład tego używam do przekierowania portu 9090 na zdalnym hoście do mojego lokalnego portu 9090 dla cherokee-admini używam podobnych ustawień dla innych sieciowych interfejsów GUI. Możesz chronić aplikacje w ten sposób, określając w konfiguracji aplikacji, że działają one tylko na localhost, tj 127.0.0.1. Na . W ten sposób nie są one dostępne z zewnątrz, ale można je przesyłać dalej ssh. Sprawdź man sshwięcej opcji za pomocą przekierowania portów (w tym X, które mogą całkowicie rozwiązać problem w inny sposób).

W zależności od konfiguracji może to być odpowiedni sposób na osiągnięcie celu bez instalowania / konfigurowania dodatkowego oprogramowania.


1

Jeśli twoja zapora na to pozwala, możesz najpierw dokonać uwierzytelnienia na poziomie zapory, jeśli złożoność haseł jest wystarczająco dobra, to powinno wzmocnić bezpieczeństwo ujawnionych usług. możesz także użyć tunelowania SSL, używając na przykład stunnel i wzajemnego uwierzytelniania.

Biorąc pod uwagę fakt, że użycie większej liczby portów jest w pewnym stopniu bezpieczniejsze, być może w odniesieniu do botów skanujących twoje IP i próbujących niektórych exploitów, ale jeśli ktoś naprawdę chce się włamać, użycie wyższych numerów portów nie zapewni większego bezpieczeństwa.


Używam pfsense, a niektóre z moich usług internetowych mają wbudowaną obsługę SSL (HTTPS). Czy nadal lepiej jest używać stunnela? Czy używanie stunnela to „uwierzytelnianie na zaporze ogniowej”?
SofaKng

1
Jak wykonać „uwierzytelnianie w zaporze ogniowej”?
wag2639

Nie wiem, czy pfsense ma taką funkcjonalność, ale na routerach Junipers możesz użyć lokalnych użytkowników (nawet RADIUS), aby udzielić dostępu do przetłumaczonego ruchu HTTP. Jeśli chodzi o Stunnel, możesz używać wzajemnego uwierzytelniania z certyfikatami, stunnel będzie szyfrować ruch HTTP za pomocą SSL i obsługiwać uwierzytelnianie.
Maxwell,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.