Jak ryzykowne jest posiadanie osobistego serwera z ssh otwartym w Internecie?


25

Kontynuacja tytułu byłaby „przy ograniczonej wiedzy na temat bezpieczeństwa w Internecie”.

Niedawno stworzyłem mały serwer z komputerami klasy debian z niskim poziomem, aby używać go jako osobistego repozytorium git. Włączyłem ssh i byłem dość zaskoczony szybkością, z jaką cierpiał z powodu brutalnych ataków i tym podobnych. Potem przeczytałem, że jest to dość powszechne i dowiedziałem się o podstawowych środkach bezpieczeństwa, aby odeprzeć te ataki (wiele pytań i duplikatów na temat błędu serwera radzi sobie z tym, patrz na przykład ten jeden lub ten ).

Ale teraz zastanawiam się, czy to wszystko jest warte wysiłku. Postanowiłem założyć własny serwer głównie dla zabawy: mogłem polegać na rozwiązaniach innych firm, takich jak te oferowane przez gitbucket.org, bettercodes.org itp. Chociaż część zabawy polega na poznawaniu bezpieczeństwa w Internecie, nie wystarczająco dużo czasu, aby poświęcić się temu, aby zostać ekspertem i być prawie pewnym, że podjąłem odpowiednie środki zapobiegawcze.

Aby zdecydować, czy będę nadal bawić się tym projektem zabawek, chciałbym wiedzieć, co naprawdę ryzykuję. Na przykład w jakim stopniu zagrożone są również inne komputery podłączone do mojej sieci? Niektóre z tych komputerów są używane przez osoby o jeszcze mniejszej wiedzy niż moja z systemem Windows.

Jakie jest prawdopodobieństwo, że popadnę w prawdziwe kłopoty, jeśli zastosuję się do podstawowych wskazówek, takich jak silne hasło, wyłączony dostęp do roota dla ssh, niestandardowy port dla ssh i ewentualnie wyłączenie logowania hasłem i użycie jednej z reguł fail2ban, denyhosts lub iptables?

Innymi słowy, czy są jakieś duże złe wilki, których powinienem się obawiać, czy chodzi przede wszystkim o odpychanie dzieciaków ze scenariusza?


Myślę, że trafiłeś w sedno, kiedy wspomniałeś, że nie masz czasu ani ochoty zostać ekspertem w dziedzinie bezpieczeństwa $ TECHNOLOGY; jest to główny powód korzystania z hostowanego rozwiązania. Jedynym innym powszechnym argumentem przy ocenie wewnętrznej w porównaniu z hostingiem jest koszt. Ponieważ github i tym podobne są bezpłatne, zasadniczo poświęcasz swój czas osobisty, aby zdobyć wiedzę na temat prowadzenia repozytorium git. Nie możemy powiedzieć ci, co powinieneś robić z czasem osobistym, ale w profesjonalnej sytuacji nie miałoby to sensu. (zastrzeżenie emptor: skomplikowane sytuacje mają więcej zmiennych).
Chris S

1
Jeśli zdecydujesz się uruchomić własny serwer, dodaj również do swojej listy rzeczy do zrobienia regularne sprawdzanie aktualizacji i luk w zabezpieczeniach dla każdej uruchomionej usługi. Samo skonfigurowanie nie wystarczy.
tydzień

Dwa słowa: klucze publiczne, jak to ujął @Stephane. Wyłącz keyboard-interactiveuwierzytelnianie i używaj tylko pubkeyuwierzytelniania.
kostix

Odpowiedzi:


14

IMO SSH to jedna z najbezpieczniejszych rzeczy do słuchania w otwartym Internecie. Jeśli naprawdę się martwisz, posłuchaj go na niestandardowym porcie wysokiej klasy. Wciąż miałbym zaporę (na poziomie urządzenia) między twoim urządzeniem a internetem i po prostu korzystam z przekierowania portów dla SSH, ale to jest środek ostrożności dla innych usług. Sam SSH jest cholernie solidny.

I nie mieli ludzie hit mój domowy serwer SSH sporadycznie (otwarte do Time Warner Cable). Nigdy nie miał rzeczywistego wpływu.

Niektóre dodatkowe rzeczy, które możesz zrobić, aby uczynić SSH bezpieczniejszym, to zapobieganie powtórnym próbom z tego samego adresu IP dla urządzenia domowego, na przykład

MaxStartups 2:30:10

w / etc / ssh / sshd_config, który ograniczy liczbę połączeń, które można utworzyć w rzędzie przed pomyślnym zalogowaniem.


Mój dostawca usług internetowych zapewnia zaporę ogniową, której parametry widziałem podczas otwierania portu dla ssh. Czy to jest to, o czym mówisz?
Alfred M.,

2
Możliwe, że niektórzy dostawcy usług internetowych zapewniają głupie urządzenie, a niektóre router z wbudowaną zaporą ogniową. Mówię tylko, że NIGDY nie jest dobrym pomysłem umieszczanie systemu operacyjnego ogólnego przeznaczenia bezpośrednio w Internecie, bez względu na podejmowane środki ostrożności. Chcesz jakieś urządzenie sprzętowe (lub coś w rodzaju DD-WRT) między tobą a paskudnym.
TheFiddlerWins

1
Skonfiguruj uwierzytelnianie klucza publicznego, jak wspomniano w innej odpowiedzi, i WYŁĄCZ uwierzytelnianie ChallengeResponse i uwierzytelnianie hasła w / etc / ssh / sshd_config.
Randy Orrison

Wiem, że to głupie pytanie, ale czy muszę kupić domenę, aby uzyskać dostęp do mojego serwera (przez ssh lub przeglądarkę) z Internetu?
TheRookierLearner

@TheRookierLearner - nie, możesz użyć adresu IP, który zapewnia ci dostawca usług internetowych. Jednak w zależności od konfiguracji sieci domowej może być współdzielony przez wszystkie urządzenia za pomocą czegoś zwanego PNAT (większość ludzi po prostu nazywa to NAT). Jeśli jesteś podobny do większości ludzi, musisz dowiedzieć się, jaki jest adres „NAT” konkretnego urządzenia, do którego chcesz uzyskać dostęp z Internetu (tylko ifconfig / ipconfig w systemie, będzie to 10.xxx, 172.16. xx lub 192.168.xx, patrz RFC 1918, aby dowiedzieć się więcej niż zależy ci na tych numerach), a następnie powiedz routerowi, aby „przekierował port” lub „DMZ” port 22.
TheFiddlerWins 15.04.15

10

Konfiguracja systemu uwierzytelniania za pomocą klucza publicznego za pomocą SSH jest naprawdę banalna i zajmuje około 5 minut .

Jeśli zmusisz wszystkie połączenia SSH do korzystania z niego, to sprawi, że twój system będzie tak odporny, jak możesz, bez inwestowania LOT-u w infrastrukturę bezpieczeństwa. Szczerze mówiąc, jest tak prosty i skuteczny (o ile nie masz 200 kont - wtedy robi się bałagan), że nieużywanie go powinno być przestępstwem publicznym.


3
Aby zmusić połączenia SSH do korzystania z uwierzytelniania za pomocą klucza publicznego po jego skonfigurowaniu, WYŁĄCZYĆ ChallengeResponseAuthentication i PasswordAuthentication w / etc / ssh / sshd_config. Raz o tym zapomniałem, ku mojemu żalowi (tylko raz i nigdy więcej).
Randy Orrison

8

Prowadzę również osobisty serwer git, który jest otwarty na świat na SSH, a także mam te same problemy z brutalną siłą co ty, więc mogę współczuć z twoją sytuacją.

TheFiddlerWins zajmuje się już głównymi konsekwencjami bezpieczeństwa otwarcia SSH na publicznie dostępnym adresie IP, ale najlepszym narzędziem IMO w odpowiedzi na próby użycia siły jest Fail2Ban - oprogramowanie, które monitoruje pliki dziennika uwierzytelnienia, wykrywa próby włamań i dodaje reguły zapory do lokalna iptableszapora ogniowa maszyny. Możesz skonfigurować zarówno liczbę prób przed banem, jak i długość banowania (moje domyślne to 10 dni).


Jak stwierdził mój komentarz do poprzedniego postu, tego właśnie używa mój NAS w domu, a po kilku miesiącach liczba prób została znacznie zmniejszona.
mveroone

2

Innym sposobem na poradzenie sobie z tym jest skonfigurowanie VPN. Zamiast łączyć się bezpośrednio z portami SSH na serwerze domowym, najpierw łączysz się z VPN, a następnie kierujesz całym ruchem przez szyfrowane, bezpieczne połączenie.

Idealnym sposobem na poradzenie sobie z tym jest zapora ogniowa, która zawiera punkt końcowy VPN, ale można również skonfigurować komputer z systemem Windows, aby działał jako serwer VPN.

Oto przykład:

http://www.howtogeek.com/135996/

Teraz pamiętaj, że odpowiednia konfiguracja zabezpieczeń wymagałaby dostępu do komputera publicznego (lub półpublicznego) odizolowanego od sieci wewnętrznej. Serwer WWW lub dowolny komputer obsługujący publicznie dostępne usługi powinien znajdować się poza bezpieczną siecią domu lub biura. Użyłbyś 2 routerów, aby stworzyć bezpieczną strefę lub strefę DMZ między tobą a Internetem.

W ten sposób, jeśli Twój serwer zostanie zhakowany, nie może być użyty jako wektor do ataku na inne komputery.

Konfiguracja powinna wyglądać następująco:

Konfiguracja DMZ


Przepraszam za mały obraz ... Nie mogę wymyślić, jak edytować mój post.
TomXP411,

2

Odpowiedzi są bardzo dobre, poleciłbym tylko dwie rzeczy:

  • Rozważ dostęp tylko przez system uwierzytelniania klucza
  • Użyj Denyhosts : zablokuje to hostom próbującym uzyskać dostęp do twojego serwera z nieprawidłowym uwierzytelnieniem
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.