Znáte to, zkusíte se připojit na SOCKS5 server na vybraném portu a zjistíte, že admin zablokoval forwarding portů (SSH tuneling) pomocí direktivy “AllowTcpForwarding no” v nastavení a vy nemůžete “zneužít” jeho linku pro vlastní potřeby.
V článku na Harvie.cz se dozvíte jak věc obejít pomocí malého workaroundu. Mimo jiné také pochopíte, jak je zakazování AllowTcpForwarding u účtů s shellovým přístupem zbytečné.
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
Tak proc je to zbytecne jsem z clanku tedy nepochopil. Shell pristup totiz neni zdaleka jedina podminka, aspon v uvedenem provedeni. Spis je hlavni podminkou dosti, rekneme, liberalni admin, kdyz uz nechci predpokladat nic horsiho.
BTW tento skvely „exploit“ byl napsan po precteni manualove stranky k OpenSSH?
AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The default is
``yes''. Note that disabling TCP forwarding does not improve se-
curity unless users are also denied shell access, as they can al-
ways install their own forwarders.
Samozrejme pokud ti zakaze pristup na net pres iptables, tak to mas blby… ale kdo by stal o takovej shell pokud to zrovna neni nejaky superpocitac? Jde hlavne o to, ze na ruznych univerzitnich shellech a freeshellech je tato kombinace (pristup k inetu povolen, ale forwarding zakazan) pomerne casta. A prece nebudeme stahovat z rapidsharu pres tor, kdyz mame od skoly 10 shellu se 100Mb linkou :-)
I kdyz jsi to nepochopil z clanku, tak jsem rad ze to chapes aspon bez nej :-) Clanek je urcen predevsim lidem kterym muze poradit.
Ze je to v manualu jsem si nevsiml. Narozdil od manualu je ale ve clanku prakticke reseni.
Nojo, manualy prece nikdo necte. Ale tak „zabezpeceny“ server, kde funguje reseni popsane v odkazovanem clanku ani zakazovat forwarding nemusi. Mozna ani nemusi davat hesla.
S takovým vytahováním běž někam…
Všichni víme, že AllowTcpForwarding se dá obejít, ale on to k tomu napsal jednoduchý návod jak na to, aby to ostatní nemuseli hledat nebo vymýšlet. Takže díky za článek. Ale taky tam mohl napsat, co dělat, když člověk stojí na „druhé straně barikády“ – jsou tu primitivní řešení zatlouct odchozí provoz na firewallu, ale to odřízne všechny uživatele – zajímavější je, vymyslet řešení, které selektivně zablokuje jen někoho. Zkouším teď řešení pomocí AppArmoru, až to budu mít ověřené, tak ho sem hodím.
To je tim ze jste Javista, ti jdou na vsechno moc slozite. Tudle jsem se ptal jak v tom frameworku zjistim IP adresu z ktery prisel dotaz a obdrzel jsem v mailu tohle:
clientadr = ((InetSocketAddress)((SocketChannel)ctx.getSelectionKey().channel()).socket().getRemoteSocketAddress()).getAddress().getHostAddress();
Tak schvalne kdo tady z mistnich Javistu pozna co je to za framework…
Noo to uz skoro vypada jako pokus o vyvolani flamewaru ;-)
krome ruznejch frmeworku jsou takovyhle slozitosti na dennim poradku microsoftich programatoru a vubec lidi co pouzivaj ty jejich API (z dokumentace na MSDN se mi vzdycky dela nevolno). Jak je mozny, ze userspace aplikace od microsoftu a jejich API je slozitejsi, nez kernel? musim kernel fakt pochvalit – sam o sobe by se mi zdal sileny, ale proti microsoftim silenostem jsem za nej rad.
kvuli jedny veci by clovek na windows musel zavolat deset funkci, kdyz to srovnam s driverama na linuxu, kdyz treba vidim jak vyvojar uz dostane ve svoji funkci veci co potrebuje a jenom je preda nejakym jedinym volanim k provedeni nejaky operace, ktera zas vsechno obstara, tak musim rict ze je to dost kontrast.
Iptables tohle řeší. Ale neumí rozlišit aplikaci, pokud bych třeba chtěl povolit TCP spojení z PHP. Jasně, že když povolím jednu aplikaci, „snadno“ se skrze ni dá omezení obejít. Ale cíl může být to maximálně znesnadnit pro lidi, co tomu moc nerozumí a nevyplatí se jim tohle studovat, při zachování použitelnosti.
Jak jsem sliboval to řešení pomocí AppArmor, tak tady je: AppArmor vs. iptables – blokování sítě. Je fakt, že pokud chceme jen omezit přístup na síť, jsou iptables jednodušší a lepší – ale vyzkoušet jsem si to musel :-)
