Logowanie na konto root poprzez ssh - zabezpieczenie serwera
Logowanie na konto root poprzez ssh - zabezpieczenie serwera
Witam.
Mam pytanie, czy istnieje opcja zezwolenia logowań na konto root tylko i wyłącznie z jednego adresu ip? Dodatkowo mam pytanie jakie kroki podjąć aby zabezpieczyć serwer wirtualny? Działają na nim takie usługi jak serwer www, apache, mysql, phpmyadmin, serwer RMS.
Pozdrawiam i dziękuje za każdą odpowiedź.
Mam pytanie, czy istnieje opcja zezwolenia logowań na konto root tylko i wyłącznie z jednego adresu ip? Dodatkowo mam pytanie jakie kroki podjąć aby zabezpieczyć serwer wirtualny? Działają na nim takie usługi jak serwer www, apache, mysql, phpmyadmin, serwer RMS.
Pozdrawiam i dziękuje za każdą odpowiedź.
http://debian.linux.pl/entries/79-Zabezpieczanie-SSH
]:->
Co do reszty poszukaj w internecie jak zabezpieczyć konkretne usługi.
Przecież nikt nie będzie siedział i dokładnie opisywał ciągnąć Cię za rączkę. Chcesz się bawić w hosting naucz się to konfigurować.
Kod: Zaznacz cały
PermitRootLogin no
AllowUsers robin
MaxAuthTries 2
Port 666
Co do reszty poszukaj w internecie jak zabezpieczyć konkretne usługi.
Przecież nikt nie będzie siedział i dokładnie opisywał ciągnąć Cię za rączkę. Chcesz się bawić w hosting naucz się to konfigurować.
W wyjątkowych sytuacjach opisanych przez AllowUsers, jeżeli Match User jest poprawny zmieniana jest konfiguracja standardowa:wenu pisze:Witam.
Mam pytanie, czy istnieje opcja zezwolenia logowań na konto root tylko i wyłącznie z jednego adresu ip?
Kod: Zaznacz cały
PermitRootLogin no
[...]
AllowUsers root@192.168.0.101 root@192.168.0.102
Match User root
PermitRootLogin yes
A po co logować się na konto roota? Loguj się na konto użytkownika nieuprzywilejowanego a później przełącz się na konto roota poleceniem su. Każdy rozsądny człowiek odradzi ci bezpośrednie logowanie na konto roota. Ja serwer zabezpieczam w ten sposób:
- Zmieniam domyślny port SSH na inny niż 22, bo ten jest zawsze skanowany i wykorzystywany do poszukiwania hasła metodą brute force.
- W iptables (firewall) otwieram port tylko dla konkretnych adresów IP/domen.
Ewentualnie wykonaj polecenie
Podajesz tylko hasło roota, polecenie się wykonuje na prawach roota na koncie użytkownika, nie potrzeba się wtedy typowo logować na konto root.
Kod: Zaznacz cały
su -c polecenie
Tak sobie pomyślałem, że jak mógłbym logować się na konto roota tylko z mojego ip to byłoby to odpowiednie zabezpieczenie. No ale, jak twierdzicie, że lepiej całkowicie odciąć roota z połączeń zdalnych to też tak zrobię. Co do wysokich portów ssh to takie podstawy znam. Adres do phpmyadmina też zmieniłem, tak na wszelki wypadek.
Co do:[cquote]Przecież nikt nie będzie siedział i dokładnie opisywał ciągnąć Cię za rączkę. Chcesz się bawić w hosting naucz się to konfigurować.[/quote]
Nie oczekuję ciągnięcia za rączkę, ale podpowiedzi np. ,,zainteresuj się tym, poczytaj o tym''. No ale w porządku, poszukam sobie
Pozdrawiam.
Co do:[cquote]Przecież nikt nie będzie siedział i dokładnie opisywał ciągnąć Cię za rączkę. Chcesz się bawić w hosting naucz się to konfigurować.[/quote]
Nie oczekuję ciągnięcia za rączkę, ale podpowiedzi np. ,,zainteresuj się tym, poczytaj o tym''. No ale w porządku, poszukam sobie

Pozdrawiam.
A jak będziesz musiał się zalogować z innego miejsca? Można takie coś zrobić tylko z jednym numerem IP i do tego logowanie poprzez su z konta użytkownika jako dodatkowe zabezpieczenie. Ale jak wiesz, że tylko z jednego ip będziesz się łączył. Najważniejsze to zmiana portu, poprzez to już od razu pozbywasz się "nadmiaru prób logowań" ewentualnie zainstalować zabezpieczenie takie jak fail2ban.
Jak musisz się logować z innego miejsca to polecam OpenVPN albo stworzenie sobie tzw "furtki". Jeżeli chodzi o "furtkę" to kiedyś coś takiego robiłem - skrypt php+bash. Wchodząc na daną witrynę podajesz login i hasło (zabezpieczenie np. przez przez htpasswd). Skrypt sprawdza Twój aktualny adres IP i poleceniem iptables otwiera dostęp do SSH z konkretnego IP. Więc w razie awarii możesz sobie taki port otworzyć z dowolnego miejsca na świecie
Robiłem to bardzo dawno i wycofałem się z tego ze względu na wdrożenie OpenVPN'a.
Jeżeli chodzi o OpenVPN'a to jest to o tyle fajne rozwiązanie, że rezygnujesz z dostępu przez SSH na interfejsie WAN (o tym za chwilę). Żeby zalogować się do OpenVPN'a musisz mieć zainstalowaną aplikację OpenVPN, która tak na dobrą sprawę może chodzić nawet na smartfonie. Do uruchomienia jej na stacji roboczej potrzebujesz 4 rzeczy: pliku konfiguracyjnego, certyfikatu serwera, klucza prywatnego i klucza publicznego wygenerowanego dla użytkownika. Łatwo to transportować na pendrivie. Nawet w razie utraty pendrive'a klucz zabezpieczony jest hasłem. Na serwerze interfejs VPN jest traktowany jako normlany interfejs sieciowy pomimo tego, że jest wirtualny. Tak więc możesz pisać na niego reguły firewalla. Tak więc blokujesz dostęp SSH na interfejsie WAN a odblokowujesz takowy na interfejsie VPN. Kombinacji może być wiele i podejrzewam, że wielu z użytkowników ma swój "patent" na zabezpieczenie serwera.

Jeżeli chodzi o OpenVPN'a to jest to o tyle fajne rozwiązanie, że rezygnujesz z dostępu przez SSH na interfejsie WAN (o tym za chwilę). Żeby zalogować się do OpenVPN'a musisz mieć zainstalowaną aplikację OpenVPN, która tak na dobrą sprawę może chodzić nawet na smartfonie. Do uruchomienia jej na stacji roboczej potrzebujesz 4 rzeczy: pliku konfiguracyjnego, certyfikatu serwera, klucza prywatnego i klucza publicznego wygenerowanego dla użytkownika. Łatwo to transportować na pendrivie. Nawet w razie utraty pendrive'a klucz zabezpieczony jest hasłem. Na serwerze interfejs VPN jest traktowany jako normlany interfejs sieciowy pomimo tego, że jest wirtualny. Tak więc możesz pisać na niego reguły firewalla. Tak więc blokujesz dostęp SSH na interfejsie WAN a odblokowujesz takowy na interfejsie VPN. Kombinacji może być wiele i podejrzewam, że wielu z użytkowników ma swój "patent" na zabezpieczenie serwera.
Ja dla ssh stosuję standardowo: zmianę portu na wysoki, niestandardowy; brak mozliwości logowania na root; ips (nie fail2ban ale równie fajny). Akurat dla takiej usługi jak ssh to rozwiązanie Packa jest ciekawe, orginalne. Niemniej można poprostu zastosować coś podobnego i bardziej popularnego, czyli port knocking. Ja preferuje własny port knocking, którego minusem jest dobra znajomość iptables (przynajmniej dla skomplikowanego systemu), ale są też programowe. Fajna sprawa.