Zdalny Dostep Po Ssh

[adams24]

Witam.

 

 

Pasuje mi zabezpieczyć dostep po ssh do jednego serwerka tak abym mógł sie logować tylko z określonego miejsca. Problem w tym że iptables odpada bo w lokallizacji której się będe logował mam zmienne IP. Mógłbym wyedytować pliki host.allow i host.deny podając domenę, z której bede się logował, ale bedzie to domena DynDNS przypisana ruterowi (bramie) ze zmiennym IP.

 

I pytanie!!!

 

Czy jak przypiszę Domenę DynDNs ruterowi ze z zmiennym IP i wyedytuję host.allow i host.deny odpowiednio czy będe mógł z tej loklalizacji sie zalogować po ssh ???

[@perl]

host.allow i host.deny to tylko dodatek, najważniejszy jest firewall, możesz go skonfigurować po adresie MAC np. http://www.cyberciti.biz/tips/iptables-mac...-filtering.html

 

ponadto w sshd.conf skonfiguruj zakaz logowania sie zdalnego na roota oraz zakaz lokalnego użycia ssh,

 

powodzenia,

 

[morsik]

Można użyć też klucza. Wyłączyć logowanie na hasło, a dostępne tylko za pomocą klucza. Wtedy się logujesz z kluczem (który jest hasłem do konta) i sshd automatycznie Cię zaautoryzuje. Niestety więcej nie powiem, bo sam tego nie używam.

[adams24]

Dzięki za podpowiedzi będe działał.

[@perl]

a najlepiej to jest użyć i klucza i hasła i filtrowania MAC/IP ja tak używam i się sprawdza

[Adi1981]

Jeśli chodzi o bezpieczeństwo, to lepszym rozwiązaniem jest ttaj jedak wyłączenie logowania na hasło. Używanie tylko klucza jest zdecydowanie mniejszą dziurą jak logowanie po haśle. Pół biedy jak sam logujesz się do systemu i masz ustawione silne hasło, ale jeśli dajesz innym dostęp do systemu to jest to w tym momencie duża dziura - któryś z użytkowników może ustawić łatwe do złamania hasło.

 

ps. Jak ktoś chce mieć w miarę bezpieczne ssh, to proponuję wyłączyć dostęp na hasło, ustawienie hosts.deny i hosts.allow na sshd, a dodatkowo skonfigurowanie denyhosts+iptables - badzo dobrze się sprawdza w przypadku ataków słownikowych/brute force na sshd. Do tego stworzyć specjalną grupę w systemie do logowania po ssh, zmienić domyślny port usługi, wyłączyć możliwość logowania na roota, oraz ustawić dodatkowo opcje:

AllowUsers (komu zezwolimy na dostęp - user musi być dodany do grupy z AllowGroups)
AllowGroups (grupa którą wcześniej stworzyliśmy)
MaxStartups 3:50:10
LoginGraceTime 15
MaxAuthTries 3

 

Po tym wszystkim powinno być _dość_ bezpiecznie.

[@perl]

Jeśli chodzi o bezpieczeństwo, to lepszym rozwiązaniem jest ttaj jedak wyłączenie logowania na hasło. Używanie tylko klucza jest zdecydowanie mniejszą dziurą jak logowanie po haśle.

nie opowiadaj bredni, jest prosta zasada im więcej jednocześnie działających zabezpieczeń tym lepiej (są pewne bardzo nieliczne wyjątki, ale ogólnie tak jest)

 

klucze można wygenerować zabezpieczone hasłem lub nie, hasło daje dodatkowe zabezpieczenie że nikt nie wykorzysta klucza w przypadku gdy zostanie on przechwycony,

 

tak więc hasło pełni bardzo ważną rolę aby sama metoda zabezpieczania kluczem była bezpieczna,

 

można powiedzieć, że właśnie żeby nie było "dziury" w logowaniu kluczem należy używać hasła,

 

 

[Adi1981]

Coś mi się wydaje że nie mówimy o tym samym _haśle_. Natępnym razem przydałoby się precyzyjniej wyrażać że chodzi ci o hasło na klucz, a nie o hasło dostępu do systemu i opcję PasswordAuthentication w sshd_config. A to co wyżej napisałem to nie żadne brednie tylko najprawdziwsza prawda w kontekście logowania na hasło vs. klucz.

[@perl]

raczej mówimy o tym samym haśle skoro wcześniej napisałem o zabezpieczeniu zarówno za pomocą klucza i hasła i jeszcze filtrowania dostępu po MAC/IP,

 

co do zabezpieczania samym hasłem to również nie ma co panikować, ważne przy tym jest pilnowanie zasad odpowiedniego dobierania hasła, kiedy hasło będzie silne, takie zabezpieczenie jest całkiem niezłe, a siłę hasła administrator może spokojnie wymusić dla użytkowników, więc nie ma się co obawiać,

 

dodatkowo można dobierać niestandardowe loginy, tak żeby cieżko było je odgadnąć, to również jest dodatkowe zabezpieczenie przed atakującymi botami,

 

 

[Adi1981]

Oczywiście, tylko jeśli zakładasz konto jakiemuś userowi, nie możesz mieć pewności że ustawi on odpowiednio mocne hasło. Stąd konkluzja że hasło to większa dziura w systemie niż klucz. Oczywiście możesz ustalić pewne reguły dla hasła, ale to nie zmieni faktu że user (np piotrek) może sobie stawićhasło: Piotrek-123 (ma duże litery, ma min 8 znaków, ma cyfry i ma znaki - a jednak to hasło wcale mocne nie jest). Sytuacja się nieco zmienia jak zakładasz konto tylko dla siebie, wtedy sam możesz coś mocnego ustawić.

Ustawiając możliwość autentyfikacji po haśle i po kluczu afaik masz możliwość logować się albo po haśle, albo kluczem, a nie że musisz mieć i klucz i hasło (czyli masz w tym przypadku dziurę jeśli ktoś ustawi słabe hasło). Natomiast jeśli masz ustawione hasło na klucz, a w configu wyłączone logowanie po haśle, wtedy aby zalogować się do systemu musisz użyć klucza, i dodatkowo wpisać hasło dla tego klucza - a to już dziura nie jest i wydaje mi się iż to jest ten przypadek o którym Ty mówisz. A wtedy na pewno nie myślimy o tym samym haśle :-)

[@perl]

Oczywiście, tylko jeśli zakładasz konto jakiemuś userowi, nie możesz mieć pewności że ustawi on odpowiednio mocne hasło. Stąd konkluzja że hasło to większa dziura w systemie niż klucz.

pozwole sobie niezgodzić się z Tobą, zacznijmy od podważenia pierwszego zdania, owszem możemy wymusić siłę hasła które tworzy user, powiem więcej możemy narzucić userowi styl haseł (np. długośc minimum 10 znaków, w tym min. 3 cyfry, 3 znaki specjalne, 4 litery) ponadto możemy użyć słownika do sprawdzania czy użytkownik nie daje zbyt łatwych haseł, a dodatkowo czy hasło zmieniane co 30 dni może zawierać tylko min.4 takie same znaki w stosunku do poprzedniego hasła, jeżeli połączymy to z blokowaniem dostępu do serwera na 30 min w przypadku podania 3 błędnych haseł lub loginu, daje to nam całkiem niezłe zabezpieczenie,

 

na tyle dobre, że kiedy na studiach starałem się z kolegami włamać na mój uczelniany serwer (którym się opiekowałęm) tą drogą się nie dało, udało sie dopiero wykorzystując kombinację dwóch exploitów,

 

PS. dodatkowo włączenie mechanizmu logowania za pomocą kluczy wyłącza klasyczne logowanie hasłem, więc jest oczywistą oczywistością że chodziło mi o hasło na klucz

[Adi1981]

I tu się zgodzę. Jeśli tylko zastosujemy dobre dodatkowe zabezpieczenia (o których też na początku już wspomniałem). Ale bez ich zastosowania hasło to wciąż spora dziura.

 

A włączenie logowania na klucz nie wyłącza automatycznie logowania na hasło - daje tylko możliwość wyboru sposobu logowania. Wyłączyć to możemy jedynie sami w configu ustawiając PasswordAuthentication na No Sam z resztą mam tak np gdy loguję się na serwerek mojej byłej uczelni, gdzie ze swojego kompa łączę się po kluczu, natomiast z innych hostów mogę się bez problemu logować przy pomocy hasła, jako że obie możliwości ą dozwolone :-)

[@perl]

I tu się zgodzę. Jeśli tylko zastosujemy dobre dodatkowe zabezpieczenia (o których też na początku już wspomniałem). Ale bez ich zastosowania hasło to wciąż spora dziura.

jakie niby dodatkowe zabezpieczenia? tutaj chodzi po prostu o konfiguracje korzystania z haseł, podobnie jak każdą usługę w systemie trzeba to skonfigurować, w swoim wyższym poście podałem przykład jak można do tego podejść

 

ogólna zasada jest taka, że nie powinno się stosować we WSZYSTKIM ustawień domyślnych (już widzę druga prawda życiowa w tym wątku )

[Adi1981]

jakie niby dodatkowe zabezpieczenia? tutaj chodzi po prostu o konfiguracje korzystania z haseł,

 

No właśnie, ale powiedz to zwykłemu userowi który sobie stawia serwer ssh zeby sobie skonfigurował politykę haseł To jest dodatkowe zabezpieczenie jeśli tylko ktoś je ustawi. Większość tego nie zrobi

A poza tym m.in. to co pisałem wcześniej:

ustawienie hosts.deny i hosts.allow na sshd, a dodatkowo skonfigurowanie denyhosts+iptables - badzo dobrze się sprawdza w przypadku ataków słownikowych/brute force na sshd. Do tego stworzyć specjalną grupę w systemie do logowania po ssh, zmienić domyślny port usługi, wyłączyć możliwość logowania na roota, oraz ustawić dodatkowo opcje (m.in):

AllowUsers (komu zezwolimy na dostęp - user musi być dodany do grupy z AllowGroups)
AllowGroups (grupa którą wcześniej stworzyliśmy)
MaxStartups 3:50:10
LoginGraceTime 15
MaxAuthTries 3

[adams24]

Pół biedy jak sam logujesz się do systemu i masz ustawione silne hasło,

 

No właśnie tak jest. Ja mam tylko dostep dos serwerka, userzy samby nie mają dostępu do powłoki, Jedną osoba która to robi jestem ja.