[elnapolva] sshfs tun

 ( szz | 2014. március 19., szerda - 19:11 )

Ezt a parancsot kellene kiadnom:
sshfs -p 1234 elhasznaloKUKACvalami.hu:/ idecsatold

Csakhogy a céges tűzfal nincs megnyitva e portra, csak a 22-esre.
Lehetne-e valami port forwardingot használni itt?
Effélét képzelnék, mint: ssh -L 8081:localhost:80 idemenjunk, csak sshfs-re.
(A tesztelést nehezíti, hogy ssh parancssori belépésem nincs a kívánt rendszerre, csak sftp.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ha nincs ssh hozzaferesed akkor hogy akarsz tesztelni?
max nezd meg ezt:
http://linux.die.net/man/1/sshfs
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

sshfs hozzáférésem van, és a fenti parancs (tűzfalmentes környezetből) megy is. Konkrétan shell hozzáférésem nincs.

Van érdemi ötletetek?

Ez így nem megoldható közvetlenül.
Ha a 1234-es porton figyel a szolgáltatás és a 22-es port van kiengedve, akkor a kapcsolat nem lesz létrehozható. A tunel nem rossz ötlet, de nem változtat azon, hogy nincs kiengedve olyan port, amelyen a túloldal figyel.
Kerülő megoldásként az jöhet szóba, hogy kerítesz valahonnan egy relay gépet: ezt a gépet a 22-es porton kell elérned, tehát ekkor a tűzfal kienged, erről a gépről pedig tovább kell tudni menni az eredeti célgép 1234-es portjára. Ekkor megteheted azt, hogy tolsz egy ssh parancsot a relay gép felé: ssh -L 2222:$IGAZICELGEP:1234 $RELAYGEP - majd az sshfs-t az sshfs -p 2222 elhasznaloKUKAC127.0.0.1:/ idecsatold paranccsal éleszted. Ekkor az sshfs forgalma első körben abba az ssh tunelbe fog menni, amely a $RELAYGEP felé épült ki, viszont azon a 22-es porton, amit a tűzfal kienged. Onnan meg már a "normál" úton megy tovább a célgép felé.
Jelzem, ez a megoldás sem 100%, mert van olyan tűzfal, amely hajlamos protokoll elemzésre, majd ha ssh-tuneligre hajazó forgalmat detektál, akkor szakítja a kapcsolatot. Nem ez a tipikus - de lehet buktatója a dolognak.

"Kerülő megoldásként az jöhet szóba, hogy kerítesz valahonnan egy relay gépet: ezt a gépet a 22-es porton kell elérned, tehát ekkor a tűzfal kienged, erről a gépről pedig tovább kell tudni menni az eredeti célgép 1234-es portjára. Ekkor megteheted azt, hogy tolsz egy ssh parancsot a relay gép felé: ssh -L 2222:$IGAZICELGEP:1234 $RELAYGEP - majd az sshfs-t az sshfs -p 2222 elhasznaloKUKAC127.0.0.1:/ idecsatold paranccsal éleszted. Ekkor az sshfs forgalma első körben abba az ssh tunelbe fog menni, amely a $RELAYGEP felé épült ki, viszont azon a 22-es porton, amit a tűzfal kienged. Onnan meg már a "normál" úton megy tovább a célgép felé."

Ez jó megoldás, csak főbelövés jár érte. Én legalábbis ezt tenném, mivel evvel a géppel aztán bármilyen tunnelt lehet csinálni, bejutva a tűzfal túloldalára. Sokkal egyszerűbb (biztonságosabb a tűzfal mögötti terület üzemeltetője szemszögéből) lenne elérni azt, hogy az 1234-en csináljon egy nat-ot a megadott gépre a tűzfalon.
--
PtY - www.onlinedemo.hu

Köszi mindezeket. Akkor inkább a (nyílt) wifis irányt választom, ami, bár lassabb, de nem vet föl ennyi problémát.

A kérdés az volt, hogy technikailag megoldható-e? Megoldható.
A dolog másik fele, hogy milyen szabályozás van? Tiltva van-e ez is? Nyilván ha tiltott, akkor nem szabad - akkor se, ha egyébként lehet.
De írtam azt is, hogy jobb tűzfalak képesek a protokoll elemzésre és így egy ssh tunel forgalmat képesek elnyírni. Ha a biztonság ennyire fontos, akkor legyen policy amely tiltja az ilyen kalóz akciókat _és_ legyen olyan tűzfal, amely élből meg is hiúsítja az ilyen irányú próbálkozásokat. (Illetve az is opció, hogy az ssh eleve csak megadott helyekre, megadott célból van kiengedve. A $RELAYGEP jó eséllyel nem lesz a listán - legális céllal semmiképp.)

Írtam, hogy a megoldás jó, csak az alapján, hogy a port tiltva van, következtettem arra, hogy talán ez nem véletlen.
--
PtY - www.onlinedemo.hu