Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
#1 2012-12-01 03:00:19
leman231 - 
Użytkownik
- leman231
- Użytkownik
- Zarejestrowany: 2012-11-26
Zabezpieczenie - konfiguracja SSH
wijtacie! Zainteresowałem się zabezpieczeniami bo to wiadomo podstawowa sprawa.
Po przeczytaniu tego artykułu, zacząłem od zmiany portu, jednak zaden następny krok nie jest przeznaczony dla mnie.
1. Mam zmienne IP.
2. Jak nie będę miał roota na vps'ie to nic nie zrobię w tych plikach do których nie mają dostępny normalni użytkownicy.
Jedyne co to myślałem aby zrobić użytkownika który miałby jako jedyny dostęp do pliku /etc/ssh/sshd_config i w razie potrzeby mógłby zmienić mozliwość logowania się na roota, czy to dobry pomysł?
Odnosząc się jeszcze do punktu 3 mógłbym pokombinować i konto roota zabezpieczyć kluczem RSA jednakże nie wiem czy to dobry sposób hehe ;)
3. W jaki sposób mogę ustawić aby dany użytkownik mógł wejść tylko do swojego katalogu, a gdy chce wyjść poza od razu go cofa? Tak aby po prostu użytkownik X nie mógł cofnąć się do folderu /home i gdzie indziej, może siedzieć tylko w swoim folderze
4. Czy są jeszcze jakieś inne dobry sposoby?
Z góry dziękuje za odpowiedzi
Ostatnio edytowany przez leman231 (2012-12-01 03:24:39)
Offline
#2 2012-12-01 08:30:19
ba10 - Członek DUG
Re: Zabezpieczenie - konfiguracja SSH
Ad.2
Zakładasz użytkownika i na niego się logujesz, a gdy masz wykonać jakieś administracyjne rzeczy używasz polecenia su. Więcej w
Kod:
man su
Ad.3
Musisz użytkownika zamknąć w tzw. "więzieniu" i albo to zrobisz za pomocą łatki na kernela grsecurity albo narzędzia jailkit. Poszukaj na forum takie tematy gdzieś się przewijały.
Ostatnio edytowany przez ba10 (2012-12-01 08:30:48)
"Jeżeli chcesz się nauczyć Linuksa, to pierwsze co musisz zrobić to odrzucić wszelkie przyzwyczajenia wyniesione z poprzedniego systemu. Twoja wiedza jest o tyle zgubna, że daje Ci poczucie że coś jednak wiesz — jednak w kontekście Linuksa prawdopodobnie nie wiesz jeszcze nic." Minio
Mój Blog, a później Tańczymy ;)
Offline
#3 2012-12-01 16:26:55
Pavlo950 - człowiek pasjonat :D
#4 2012-12-01 16:34:45
Bitels - Użytkownik
- Bitels
- Użytkownik
- Zarejestrowany: 2012-10-31
Re: Zabezpieczenie - konfiguracja SSH
Niestety z tego co mi wiadomo to nie. Sam swego czasu szukałem łatwiejszego rozwiązania.
Offline
#5 2012-12-02 19:43:42
winnetou - złodziej wirków ]:->
Re: Zabezpieczenie - konfiguracja SSH
Ale wystarczy dać uprawnienia na 711 lub 710 na katalog /home
Owszem user po wydaniu polecenie "cd /home" wejdźie do tego katalogu ale nie zobaczy co tam jest (ls czy echo * nie działają). Taki pseudojail ;)
Offline
#6 2012-12-02 23:01:42
chmuri - [=Centos=]
#7 2012-12-03 03:05:34
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/random
- Zarejestrowany: 2008-01-07
Re: Zabezpieczenie - konfiguracja SSH
A nie lepiej skorzystać z wbudowanej funkcji ssh tworzącej chroota?
Do sftp mmożna chrootować do folderu domowego, przy ssh jest więcej roboty, bo ssh standardowo nie pozwoli założyć chroota z shellem na folderze, jeśli root nie jest właścicielem folderu.
Mozna to obejść albo u mieszczajac foldery pacjentów w /home/user/user, gdzie /home/user należy do roota i ma chmod 700, a dopiero /home/user/user jest domowym folderem pacjenta, albo pomajstrować w źródlach ssh,.
I oczywiscie skombinować w tym chroocie/jailu jakąś powłokę, np jailkitem.
Tu conieco o chroocie w ssh:
http://www.howtoforge.com/restricting-users-to-sftp … ebian-squeeze
Do tego grsec:
Kod:
sysctl -w kernel.grsecurity.chroot_caps=1; sysctl -w kernel.grsecurity.chroot_deny_chmod=1; sysctl -w kernel.grsecurity.chroot_deny_chroot=1; sysctl -w kernel.grsecurity.chroot_deny_fchdir=1; sysctl -w kernel.grsecurity.chroot_deny_mknod=1; sysctl -w kernel.grsecurity.chroot_deny_mount=1; sysctl -w kernel.grsecurity.chroot_deny_pivot=1; sysctl -w kernel.grsecurity.chroot_deny_shmat=1; sysctl -w kernel.grsecurity.chroot_deny_sysctl=1; sysctl -w kernel.grsecurity.chroot_deny_unix=1; sysctl -w kernel.grsecurity.chroot_enforce_chdir=1; sysctl -w kernel.grsecurity.chroot_execlog=0; sysctl -w kernel.grsecurity.chroot_findtask=1; sysctl -w kernel.grsecurity.chroot_restrict_nice=1;
I skrypciarzom dziękuję za uwagę :D
I nie radzę kompletnego nieporozumienia, jakim jest zabytek w postaci OpenVZ, ale KVM czy LXC, które są aktualnie najprostszymi rozwiązaniami, jeśli to mają być serwery za 10 zl.
KVM to prawdizwa wirtualizacja, natomiast LXC to taki sam "chroot na sterydach", jak OpenVZ.
U mnie KVM bardzo grzecznie śmiga na jaju z Grsec/PaX, co z Xenem i OpenVZ jest niezbyt wykonalne.
Proces:
Kod:
pacjent 8713 73.0 1.1 1386612 47196 pts/8 Sl 03:06 0:15 /usr/bin/qemu-system-x86_64 -enable-kvm -hda /media/box/FreeBSD9.img -m 1024 -net nic,macaddr=00:1d:82:ac:3f:65 -net tap,ifname=tap1,script=no,downscript=no -alt-grab -name FreeBSD9 -boot d
Kod:
cat /proc/8713/status | grep PaX PaX: PemRs
Do tego jeszcze cgroup:
Kod:
cat /proc/8713/cgroup 13:hugetlb:/ 12:net_prio:/ 11:perf_event:/ 10:blkio:/kvm/fbsd 9:net_cls:/kvm/fbsd 8:freezer:/ 7:devices:/ 6:memory:/kvm/fbsd 5:cpuacct:/ 4:cpu:/kvm/fbsd 3:debug:/
Pozdrawiam
;-)
Ostatnio edytowany przez Jacekalex (2012-12-03 03:28:02)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline