[NCLUG] ssh question
Scott Scriven
nclug at toykeeper.net
Thu Oct 9 21:54:08 MDT 2008
The short version: The ssh / proxy approach is less powerful, but
gives you fewer opportunities to shoot yourself in the foot.
Everything below is just my rambling about the details, in case
Jim is interested.
* Bob Proulx <bob at proulx.com> wrote:
> For one ssh tunnels don't show up on a list of system
> interfaces and don't show up in routing tables. This might be
> more of a steganography issue.
Yeah, if someone audits your computer from inside, a VPN would be
visible. OTOH, the proxy-over-ssh approach is visible too, by
looking at Firefox settings. And in either case, any history or
cache on your work computer could contain inappropriate data.
Looking from the outside, such as a company router, an openVPN
connection would normally look a bit different than an ssh
connection. If that matters, it's possible to change its
appearance, but that involves non-default settings so it's less
convenient.
I've occasionally had to run openVPN over a ssh tunnel, due to
extremely limited outside access. It's less efficient, but also
invisible from the outside.
> Setting up a full vpn with network routing and everything would
> almost certainly raise some red flags if this is a corporate
> desktop.
If your work doesn't allow you to bypass their network, you're
asking for trouble. Maybe that's okay where you work, but don't
try to sneak data out of the top secret military labs at Lockheed
Martin. :)
> For another in that same case setting up a fully routed VPN
> while still maintaining access to the local network is a more
> complicated situation.
Yes, it helps to have a basic understanding of routing.
The way the routing table works, it's a series of targets, going
from most specific to least specific. The destination of each
packet falls through the table from the top until it hits
something which matches, and then the packet does whatever that
entry says.
A typical desktop on a large internal network will generally have
a routing table like this: (run 'ip route show' or 'ip ro')
# direct link to internal corporate network
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.1.101
# everything else goes over corporate router
default via 10.0.0.1 dev eth0
This says, basically... If your destination is on the local
network, talk to it directly. Otherwise, send the packets to the
gateway (10.0.0.1) for further processing.
But with openVPN set up how you might want, the routing is more
complicated:
# static route to home
74.95.87.113 via 10.0.0.1 dev eth0
# direct link to openVPN
192.168.8.13 dev tun0 proto kernel scope link src 192.168.8.14
# static route to home network (optional)
192.168.1.0/24 via 192.168.8.13 dev tun0
# static route to openVPN network (optional)
192.168.8.0/24 via 192.168.8.13 dev tun0
# static route to external corporate network (optional)
129.82.0.0/16 via 10.0.0.1 dev eth0
# direct link to internal corporate network
10.0.0.0/8 dev eth0 proto kernel scope link src 10.1.1.101
# everything else goes over openVPN
default via 192.168.8.13 dev tun0
This may be a little more than you'd really need, and it may not
be completely accurate (just spewing some data from the top of my
head), but it should at least be fairly close. Some entries are
redundant, but make it easier to change the default route if
desired.
Basically, this routing table talks normally to your corporate
servers, and sends everything else over an encrypted tunnel.
> You would need to make sure the routing is correct for two sets
> of networks. Doing this incorrectly can compromise the
> security of the local network.
Definitely watch out for that. The defaults are pretty safe, but
you could accidentally create a back door into either your
corporate network or your home network. You should specifically
make sure your workstation is not forwarding packets -- the two
networks should stay separate. Otherwise, your Windows box at
home could get compromised and launch attacks on the internal
servers at work. So, make sure your workstation is not a router.
Hopefully this helps explain some of the details.
-- Scott
More information about the NCLUG
mailing list