Sshd Gatewayports

[Vlada Macek]

[Autor citovane zpravy: Jan Houstek, cas odeslani: 23.08.2004 00:49]

Disclaimer: Chtel bych predeslat, ze tuto vymenu nepovazuji za hadku s
panem Houstkem. Myslim, ze mame v zasade podobne nazory, jen jine
pohledy nektere skutecnosti. Tak treba budou informace v diskuzi
prinosem pro zdejsi ucastniky, kteri se sitovanim zacinaji. :-)


>> A to ja to zase chapu: Aby nad tim mel vladu spravce serveru kde
>> bezi sshd a ne ten, kdo pousti ssh. Jako root serveru si rozhodne
>> rad ponecham pravo rozhodnout, zda mi nekdo instaluje na serveru
>> neomezeneho posluchace, ktery je druhym koncem nekde mimo mou sit.
>
> Hmmm, kdyz ma nekdo shell, tak typicky muze delat mnohem zakernejsi
> veci nez pouhe poslouchani na vysokem portu a posilani toho obsahu
> kamsi. (Pochopitelne je mozne, ze je uzivatelum sitova aktivita
> nejakym zpusobem odeprena a pak jedinym zpusobem, jak nekde
> poslouchat, zustava sshd, nicmene je to dost nestandardni situace.)

Nestandardni, nicmene dobre predstavitelna. Jeste je dalsi moznost: Jsem
za NATem, jednou jsem nutne na chvili potreboval verejny poslouchaci
port a mel jsem k dispozici server, kde bylo GatewayPorts No. Pak staci
spustit ssh -R x:h:z listener, kde program listener nedela nic jineho,
nez ze posloucha na *:y a pri prichodu spojeni otevre a preposila na
localhost:x. Ucinne a i v Pythonu trivialni.

Takze samozrejme, pokud mam jednou na serveru ssh shellovy ucet, muzu
ledacos (i kdyz zas jen to, co mi spravce povolil jinymi prostredky).
Omezuje me zakaz poslouchani lokalnim firewallem serveru, pak je mi i
sshd nanic.

BTW, upozornuji na neprilis znamou skutecnost: Tunelovat jeden
spolehlivy protokol jinym je neefektivni. Vice viz napr.
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html. Nevim presne, zda
se to tyka i port forwardingu pomoci ssh.


>> a za druhe pokud na to spravce serveru se sshd mysli, muze shell
>> uzivatelum zakazat nebo omezit. Pak se kazdy musi podridit
>> nastaveni volby GatewayPorts.
>
> Situace, kdy uzivatele nemaji shell, ale mohou si libovolne
> forwardovat porty, je podle me dost specificka a neni nutne, aby na
> ni bylo pamatovano v defaultni konfiguraci.

Vidim to tak, ze je to kvuli bezpecnosti zakazano a spravce to muze
povolit. Tvurci uznavaji, ze je to specificke nastaveni, a proto je
implicitni, aby se o nej vetsina nemusela starat a byla vice klidu. Proc
by nemohla existovat aplikace ssh se zakazanym ci omezenym shellem a
moznosti forwardovat si porty (omezene lokalnim firewallem)?


>> Vidim to jako bezpecnostni vlastnost. Jednak zarizeni si toho sameho
>> jen se shell uctem neni takova trivka
>
> nc -l -p 12345 | whatever

Jiste, pro vas trivka. Podle meho nazoru je soucasti zabezpeceni kazdeho
systemu ztizeni nebo znemozneni pristupu crackerum pod urcitnou urovni
schopnosti. A chci tu uroven co nejvys. Myslim, ze kdyz nekomu o
vniknuti do systemu SKUTECNE pujde, nic mu nezabrani, aby se do nej
casem dostal. Na nej tedy zabezpeceni namireno primo neni.


> Pripadne uzivateli nic nebrani spustit si vlastni sshd.

Jo, pokud ho tam ma nebo ho tam muze dostat. A taky pokud ho tam muze
spustit.


> K cemu podle vas pak to ssh vubec maji? Ke spousteni nejakych
> konkretnich prikazu skrze pubkey autentizaci nebo specialni shell? To
> pak ale nepotrebuji portforwarding vubec a povoleni Gatewayports se
> toho nijak netyka.

No treba prave pro aplikace s omezenou mnozinou spustitelnych prikazu, v
krajim pripade s jednim prikazem. Napadaji me BBSky, univerzitni
informacni systemy, apod...

Zkratka, me prijdou vcelku predstavitelne vsechny ctyri varianty
omezeny/neomezeny shell x GatewayPorts Yes/No. Proto povazuji tuto volbu
za prinos flexibilite nastaveni meho serveru a jsem spokojeny i s jejim
implicitnim nastavenim. Shellem mam ted na mysli robatko spoustene ssh
demonem, ne nutne prikazovy radek z /etc/shells.


> P.S. Nicmene je mi jasne, ze to je brek na spatnem hrobe, spis to
> zkusim nadhodit openssh devel listu (pokud me drive nekdo
> nepresvedci, ze to je totalni ptakovina).

Podle me je to paka spravce serveru, a proto ma zustat v jeho rezii.

Vlada

------------- další část ---------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://www.linux.cz/pipermail/linux/attachments/20040823/95c81dac/attachment.sig>