Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] - نسخه متنی

Rob Flickenger

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید












Hack 93 Forwarding Ports over SSH




Keep network traffic to arbitrary ports secure
with SSH port forwarding.


In addition to providing remote shell
access and command execution, OpenSSH can also forward arbitrary TCP
ports to the other end of your connection. This can be extremely
handy for protecting email, web, or any other traffic that you need
to keep private (at least, all the way to the other end of the
tunnel).


SSH accomplishes local forwarding by binding to a local port,
performing encryption, sending the encrypted data to the remote end
of the SSH connection, then decrypting it and sending it to the
remote host and port you specify.

Start an SSH tunnel with the
-L switch (short for Local):


root@laptop:~# ssh -f -N -L110: mailhost :110 -l user mailhost 


Naturally, substitute user with your
username, and mailhost with your mail
server's name or IP address. Note that you will have
to be root on laptop for this example, since
you'll be binding to a privileged port
(110, the POP port). You should also disable any
locally running POP daemon (look in
/etc/inetd.conf) or it will get in the way.


Now to encrypt all of your POP traffic, configure your
mail client to connect to localhost port
110. It will happily talk to mailhost as
if it were connected directly, except that the entire conversation
will be encrypted.


The -f forks SSH into the background, and
-N tells it not to actually run a command on the
remote end (just do the forwarding). If your SSH server supports it,
try the -C switch to turn on
compressionthis can significantly improve the time it takes to
download your email.


You can specify as many -L lines as you like when
establishing the connection. To also forward outbound email traffic,
try this:


root@laptop:~# ssh -f -N -L110:mailhost:110 -L25:mailhost:25 -l user mailhost


Set your outbound email host to localhost,
and your email traffic will be encrypted as far as
mailhost. This generally is only useful if
the email is bound for an internal host, or if you
can't trust your local network connection (as is the
case with most wireless networks). Obviously, once your email leaves
mailhost, it will be transmitted in the
clear, unless you've encrypted the message with a
tool like PGP or GPG.


If you're already logged into a remote host, and
need to forward a port quickly, try this:



Press ENTER.



Type ~C.



You should be at an ssh> prompt. Enter the
-L line as you would from the command line.




For example:


rob@catlin:~$ 
rob@catlin:~$ ~C (it doesn't echo)
ssh> -L8080:localhost:80
Forwarding port.


Your current shell then forwards local port 8000 to
catlin's port 80, as if you had
entered it in the first place.


You can also allow other (remote) clients to connect to your
forwarded port with the -g switch. If
you're logged in to a remote gateway that serves as
a NAT for a private network, then a command like this:


rob@gateway:~$ ssh -f -g -N -L8000:localhost:80 10.42.4.6


forwards all connections from gateway's port 8000 to
internal host 10.42.4.6's port 80. If the gateway
has a live Internet address, anyone from the Net is allowed to
connect to the web server on 10.42.4.6 as if it were running on port
8000 of the gateway.


One last point worth mentioning: the forwarded host
doesn't have to be
localhost; it can be any host that the
machine you're connecting to can access directly.
For example, to forward local port 5150 to a web server somewhere on
an internal network, try this:


rob@remote:~$ ssh -f -N -L5150:intranet.insider.nocat:80 gateway.nocat.net


Assuming that you're running a
TLD[Hack #56] of .nocat, and that gateway.nocat.net also has a connection to
the private .nocat network, all
traffic to 5150 of remote
is obligingly forwarded to intranet.insider.nocat:80. The address
intranet.insider.nocat
doesn't have to resolve in DNS to
remote; it isn't looked
up until the connection is made to gateway.nocat.net, and then
it's gateway that does the
lookup. To securely browse that site from
remote, try connecting to http://localhost:5150/.


Although SSH also has functionality for acting as a SOCKS 4 proxy
(with the -D switch [Hack #92]), it just
isn't well suited for routing all network traffic to
the other end of a tunnel. You can use a real

encapsulating tunnel
such as vtun [Hack #98] in conjunction with SSH
to forward everything.


SSH is an incredibly flexible tool, with much more functionality than
I can cover here. See the references below for more fun things you
can do with SSH.



See Also



man ssh



SSH, The Secure Shell: The Definitive Guide
(http://www.oreilly.com/catalog/sshtdg/) by
Daniel J. Barrett and Richard Silverman
(O'Reilly)




/ 158