Ako obmedziť používateľov Vášho servera len na ich lokálny priečinok? Ako povoliť pre niektorých len SFTP či SCP? Prípadne ako pre niekoho SSH úplne zakázať? Ako ochrániť systém? Pokúsim sa tu popísať všetky dostupné metódy aj keď nevylučujem, že ich bude viac.
A k čomu je to vlastne dobré?
V praxi sa neraz stáva, že potrebujete dať užívateľom prístup k serveru. Či už na nahrávanie/sťahovanie súborov alebo pre prácu spojenú so serverom a programami na ňom. V prvom prípade nás napadne využitie protokolu FTP, ktorý sa dnes moc nenosí (hoc sa stále hojne využíva pre svoju jednoduchosť, najmä webhosting službami). V tom druhom prípade sa na vzdialený prístup využíval Telnet, no dnes na jeho použitie v tejto súvislosti radšej zabudnime. V oboch prípadoch je nedostatok spoločný – nešifrovaná komunikácia medzi Vami a serverom.
Načo inštalovať ďalšiu službu v podobe šifrovaného FTPS (aj keď to je riešenie) keď už na serveri s najväčšou pravdepodobnosťou beží SSH pre vzdialený prístup? Ten sám v sebe nesie aj taký SCP či SFTP (FTP over SSH) protokol pre kopírovanie súborov. No na druhej strane, keď už niekomu povolím tieto služby – ako mu zakázať vzdialený prístup aby nemohol pokukovať po zvyšku servera? Skúsim uviesť všetky možnosti ktorými môžete obmedziť slobodu užívateľov na serveri využívajúcich práve SSH.
Všetky tu uvedené postupy platia a boli odskúšané na operačnom systéme Linux a OpenSSH.
Začnem od tých najjednoduchších a zároveň najmenej efektívnejších. 🙂
0. AllowUsers, DenyUsers, Groups a /bin/false 🙂
V prípade, že nechcete pre užívateľa povoliť žiadne funkcionality plynúce z OpenSSH (a nie len z neho, prihlásenie užívateľa nebude možné ani cez lokálnu konzolu), je to najlepšie:
# chsh -s /bin/false user0
Prípadne sa môžme zamerať na direktívy AllowUsers, AllowGroups, DenyUsers, DenyGroups v /etc/ssh/sshd.conf:
DenyUsers user1 user2 user3 DenyGroups group1 group2 AllowUsers user1 user2 AllowGroups group1 group2
1. Restricted Bash Shell – rbash
Ako už názov napovedá – jedná sa o akúsi obmedzenú verziu štandardného shellu. Z man stránky vyplýva, že pod rbash-om nie je dovolené:
- Prechádzať adresáre príkazom
cd
. - Nastavovať alebo rušiť hodnoty premenných
SHELL
,PATH
,ENV
, aleboBASH_ENV
. - Používať príkazy ktoré obsahujú lomítka.
- Zadávanie názvu súboru, ktorý obsahuje lomítko ako argument
- To isté čo vyššie ale aj z pomoci voľby -p
- Import definície funkcií z prostredia shellu pri spustení.
- Parsovať hodnoty
SHELLOPTS
z prostredia shellu pri spustení. - Presmerovávať výstupy pomocou operátorov ‘>’, ‘>|’, ‘<>’, ‘>&’, ‘&>’, a ‘>>’ .
- Použiť
exec
- Pridávať alebo odoberať vstavané príkazy s -f a -d možnosťami
enable
. - Využívať príkaz
enable
pre povolenie niektorých operácií. - Vypnúť restricted mód s ‘set +r’ alebo ‘set +o restricted’.
Aplikácia a test
# chsh -s /bin/rbash user1
Výsledkom, po prihlásení užívateľa „user1“ cez ssh:
user1@debian:~$ cd -rbash: cd: restricted user1@debian:~$ echo "Hello world" >test.txt -rbash: test.txt: restricted: cannot redirect output
Nevýhody
Užívateľovi nič nebráni (alebo len veľmi málo) spustiť akýkoľvek plnohodnotný shell, čím defakto úplne obíde obmedzenia rbash-u. Aj keď čiastočne vieme túto nevýhodu potlačiť správnym nastavením práv k súborom na filesystéme je toto asi najmenej vhodné riešenie. Aj pret0 sa rbash častejšie používa v spojení s chrootom (o tom až nižšie).
Okrem toho:
- SFTP nefunguje
- SCP funguje obmedzene (keďže nie je možné vchádzať do adresárov, je možné súbory len uploadovať/downloadovať z koreňového adresára)
2. Uväznenie (jail) SFTP
Omnoho elegantnejší prístup, ak chcete užívateľom naozaj povoliť len upload/download súborov na server bez možnosti ich vpustiť cez SSH dovnútra. Trošku pracnejší ale stále dostatočne jednoduchý a efektívny.
Začneme editáciou a pridaním riadkov do /etc/ssh/sshd.conf:
Subsystem sftp internal-sftp # Povolí, pouzivat sftp. Pridajte len ak chyba... # Tuto sekciu pridakte az na uplny koniec sshd.conf # miesto direktivy Group je možné použiť aj User a odkazovatsa na konkretneho uzívatela Match Group sftponly ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no
Samozrejme je nutná prístomnosť skupiny sftponly v systéme:
# groupadd sftponly
Okrem toho, domovský adresár užívateľa na ktorého chceme aplikovať obmedzenie musí byť vlastnený root-om. Takže:
# chown root:root /home/user2
Na koniec priradíme aj daného užívateľa do cieľovej skupiny:
# gpasswd -a USER sftponly
Užívateľovi funguje teda len sftp. Pri pokuse o vzdialený prístup pomocou ssh nabehne hláška:
Could not chdir to home directory /home/user2: No such file or directory This service allows sftp connections only.
Nevýhody
Pozornejší si iste všimnú práva na domovskom adresári užívateľa, priradené pre root:root. Užívateľ sa síce prihlási a má prístupnú len funkcionalitu sftp, čiže SSH ani SCP fungovať nebudú ale kvôli nastaveným právam na roota nebude môcť do domovského adresára ani nič zapísať. Preto je žiadúce vytvoriť pod jeho domovským adresárom ďalší priečinok, napr:“upload“, ktorému priradíme práva:
chown user2:sftponly /home/user2/upload
Užívateľ takto získa plnú kontrolu až pod týmto priečinkom.
3. SSH Chroot Jail
Tretím, pracnejším a zároveň najelegantnejším spôsobom je podhodené – izolované prostredie, nezávislé od toho koreňového na ktorom celý systém beží. Vhodné pre tých, ktorý z nejakého dôvodu potrebujú aj SSH prístup na vzdialenú konzolu. Tento spôsob je zároveň najzložitejší na konfiguráciu ale je aj najbezpečnejší pre Váš systém do ktorého chcete mať naďalej prístup len vy. Veľmi často sa používa aj na spustenie iných sieťových služieb ako apache, mysql či ftp ktoré v rámci takéhoto prostredia bežia a izolujú sa pre prípad, že by ich niekto chcel zneužiť.
Vytvorme skupinu, ktorej sa bude jail týkať.
# groupadd jailusers # adduser -g jailusers user3
V ďalšom kroku vytvoríme v jailu stromovú, systémovú štruktúru adresárov
# mkdir -p /var/jail/{dev,etc,lib,usr,bin} # mkdir -p /var/jail/usr/bin # chown root:root /var/jail
Potrebovať budeme aj /dev/null
#mknod -m 666 /var/jail/dev/null c 1 3
Okopírujeme ešte niektoré minimálne nutné súbory:
# cd /var/jail/etc # cp /etc/ld.so.cache . # cp /etc/ld.so.conf . # cp /etc/nsswitch.conf . # cp /etc/hosts .
Teraz si premyslíme aké príkazy chcem užívateľovi sprístupniť. Určite budeme potrebovať nejaký shell a dajme tomu neškodné príkazy ls, dir a cat.
# cd /var/jail/usr/bin # cp /usr/bin/ls . # cp /usr/bin/dir . # cp /usr/bin/bash . # cp /usr/bin/cat
Tá komplikovanejšia časť prichádza až teraz. Každý z okopírovaných príkazov totiž potrebuje pre svoj beh aj knižnice. Musíme teda zistiť zoznam knižníc potrebné pre chod daného príkazu a taktiež ich okopírovať do nášho prostredia jailu.
# ldd /bin/bash linux-vdso.so.1 (0x00007ffdd23f3000) libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f826a8ea000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f826a6c0000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f826a4bc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f826a111000) /lib64/ld-linux-x86-64.so.2 (0x00007f826ab0f000) # ldd /bin/ls linux-vdso.so.1 (0x00007fff995de000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f3430dd6000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f3430bcd000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3430822000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f34305b4000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f34303b0000) /lib64/ld-linux-x86-64.so.2 (0x00007f3430ffb000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f34301ab000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f342ff8e000)
Toto môže byť utrpenie zvlášť pri zložitejších programoch, ktoré dokážu potrebovať desiatky knižníc. Ale je to nutnou medzi-cestou k dokonalej bezpečnosti. 🙂
Svoje snaženie zakončíme pridaním krátkej sekcie do /etc/ssh/sshd.conf:
Match group jailusers ChrootDirectory /var/jail/ X11Forwarding no AllowTcpForwarding no
Týmto spôsobom dokážeme užívateľovi predhodiť dokonale izolované prostredie s funkčným SSH, SCP a SFTP v ktorom aj keď spraví nejaké škody – neohrozí to funkčnosť nášho vlastného systému.