Need VPN Firewall security advice

Hi All,

I am about to put a port forward in my IPTABLES
firewall to allow a remote Windows laptop to
run a VNC on a desktop inside my firewall.

The port forward checks to remote end's IP address,
protocol type, and port before doing the forward.
the VPN required a password in addition to the key.
The user is very good about keeping the password
separate from the laptop, in case it gets stolen.
(The password is really, really nasty!) To break
in, a thief would need both the password and the IP
address of the distant end.

Question: at this point in my description, do
you all feel comfortable with what I am planning?


If so, on to my next question. When the rest
of the remote user figure out how the above works,
they will want it too. Problem: the rest of them
are on dynamic addresses. This would mean that
I would have to open up the firewall to access
a great deal of additional IP addresses.

A thief would only need the password. And those
annoying port scanner would be able to make contact
the desktop's VPN (the password guessing would start
in earnest). The idea of doing this give me
hives! :'(

Does anyone know of a secure way to handle these
dynamic IP remote users?

Many thanks,
--Tony
aewell@gbis.com




--
-------------------------
I Fish. Therefore, I am.
-------------------------

Op Fri, 20 Aug 2004 19:45:00 -0700 schreef Anthony Ewell:

> Hi All,

[snip]

> Question: at this point in my description, do
> you all feel comfortable with what I am planning?

Relatively, yes. I'm not sure whether there are known vulnerabilities in
realvnc, so I'm *not* using it from outside of my firewall. (Great
program, BTW ! )

> Does anyone know of a secure way to handle these
> dynamic IP remote users?

Yes: *DON'T* !!! Since you seem to be at least partly in control of
this network, simply put your foot down and tell them that you *will
not* allow it because of the risks involved.

The worst that can happen is that they go to your supervisor and that
(s)he overrules you, but hey, then it's out of your hands, isn't it?

> Many thanks,
> --Tony
> aewell@gbis.com

Always a pleasure.


--
There's no place like 127.0.0.1
Gerard Wassink http://linux.family.filternet.nl
http://freeware.family.filternet.nl
Linux counter #360967, "In a world without fences, who needs gates?"

Anthony Ewell <aewell@gbis.com> wrote in message news:<2onr96Fcgmh2U3@uni-berlin.de>...
> Hi All,
>
> I am about to put a port forward in my IPTABLES
> firewall to allow a remote Windows laptop to
> run a VNC on a desktop inside my firewall.
>
> The port forward checks to remote end's IP address,
> protocol type, and port before doing the forward.
> the VPN required a password in addition to the key.
> The user is very good about keeping the password
> separate from the laptop, in case it gets stolen.
> (The password is really, really nasty!) To break
> in, a thief would need both the password and the IP
> address of the distant end.
>
> Question: at this point in my description, do
> you all feel comfortable with what I am planning?

Probably not -- the VNC connect password is encrypted (barely) but all
subsequent traffic passes unencrypted. Will compression be enough to
discourage the bad guys? Your call. At least check into using SSH or
SSL (stunnel) to provide end-to-end encryption of all traffic. SSL
with certificates provides reasonable authentication security as well
;-)

> If so, on to my next question. When the rest
> of the remote user figure out how the above works,
> they will want it too. Problem: the rest of them
> are on dynamic addresses. This would mean that
> I would have to open up the firewall to access
> a great deal of additional IP addresses.

This wouldn't even help if the "inside" IPs are on a private network
,ie., out 10.x, 172.16.x, or 192.168.x friends. Provides a great
excuse for why not everyone can have VNC access ;-) Just play dumb
re: tunneling schemes!

> A thief would only need the password. And those
> annoying port scanner would be able to make contact
> the desktop's VPN (the password guessing would start
> in earnest). The idea of doing this give me
> hives! :'(
>
> Does anyone know of a secure way to handle these
> dynamic IP remote users?
>
> Many thanks,
> --Tony
> aewell@gbis.com

Agree with WG that you should make someone higher up make that call
and accept responsibility. Part of that is for you to formally draw
up access/security plans and get a signature -- bet that cuts down on
the number of people clamoring for this nifty new feature.

Go slow, get familiar with the product and the risks involved and
start researching _secure_ access now -- plan for the day that someone
higher up says, "Just do it!"

my 2 c's,
prg
email above disabled

P Gentry wrote:

>> I am about to put a port forward in my IPTABLES
>>firewall to allow a remote Windows laptop to
>>run a VNC on a desktop inside my firewall.
>>
>> The port forward checks to remote end's IP address,
>>protocol type, and port before doing the forward.
>>the VPN required a password in addition to the key.
>>The user is very good about keeping the password
>>separate from the laptop, in case it gets stolen.
>>(The password is really, really nasty!) To break
>>in, a thief would need both the password and the IP
>>address of the distant end.
>>
>> Question: at this point in my description, do
>>you all feel comfortable with what I am planning?
>
>
> Probably not -- the VNC connect password is encrypted (barely) but all
> subsequent traffic passes unencrypted. Will compression be enough to
> discourage the bad guys? Your call. At least check into using SSH or
> SSL (stunnel) to provide end-to-end encryption of all traffic. SSL
> with certificates provides reasonable authentication security as well
> ;-)

Hi P.,

I should have made it more clear that TightVNC has to
transverse OpenVPN to make connection with the other end.
I am presuming that OpenVPN will provide enough (encrypted)
security. Does this change your evaluation?

As far as the floating IP's, I have complete control
over the firewall. I am a private contractor, not an
employee. My customer give me the final say on everything
to do with the network. They are dear people -- the ones
you want to take very, very good care of. Consequently, I
am very, very protective of them. I even have them off
of IE and OE (Firebird and Thunderbird are awesome).
They have only caught one virus in the seven years I have
worked for them! :-)

As I stated before, floating IP's through the firewall
give me the hives. Since they give all of you the hives as well,
they are out. If the other users want VPN access, I will arrange
with their ISP's for a fixed address. (My other remote
users will love any excuse to upgrade to DSL at
their homes. So, it is a win-win situation for me!)

I appreciate all of your wisdom and assistance in
this matter. :-)

--Tony

Anthony Ewell <aewell@gbis.com> wrote in message news:<2opro7Fdcjj4U1@uni-berlin.de>...
[snip]
>
> Hi P.,
>
> I should have made it more clear that TightVNC has to
> transverse OpenVPN to make connection with the other end.
> I am presuming that OpenVPN will provide enough (encrypted)
> security. Does this change your evaluation?

IMO, for the average (and even above) scenario, it doesn't get much
better than OpenVPN ;-)

> As far as the floating IP's, I have complete control
> over the firewall. I am a private contractor, not an
> employee. My customer give me the final say on everything
> to do with the network. They are dear people -- the ones
> you want to take very, very good care of. Consequently, I
> am very, very protective of them. I even have them off
> of IE and OE (Firebird and Thunderbird are awesome).
> They have only caught one virus in the seven years I have
> worked for them! :-)
>
> As I stated before, floating IP's through the firewall
> give me the hives. Since they give all of you the hives as well,
> they are out. If the other users want VPN access, I will arrange
> with their ISP's for a fixed address. (My other remote
> users will love any excuse to upgrade to DSL at
> their homes. So, it is a win-win situation for me!)
>
> I appreciate all of your wisdom and assistance in
> this matter. :-)
>
> --Tony

OK, you're already far down the road to setting up a secure solution
via OpenVPN ;-)

This setup is about as secure as you can reasonably get and will not
_require_ static IPs for the remote clients -- all authentication is
user based, not host based. That's the nice benefit of SSL/TLS
encryption/authentication ;-)

The biggest hassle is the initial setup -- to be expected -- and the
"ongoing" certificate management. For a reasonably small office this
shouldn't be too bad.

The setup on your end should give you some idea what sort of
problems/questions the clients will have when first using the service
-- after a few goes most people have a good enough grasp to make it
work just fine ;-)

One nice thing I noticed about the the 2.0.x (still beta) version is
the scalabilty -- the code layering is much improved. And a benfit
for you and your client is that cert revocation will allow you to
disenable a user's cert wehnever the need arises.

Try this for a quick/concise overview of the security features then go
on from there:
http://www.inyotech.com/vpn_infrastructure.php
the OpenVPN site has lots of goodies.

Also check the net/Google to find some examples of people using
OpenVPN to tunnel TightVNC -- best to know beforehand before
travleling to far down that road. And keep in mind that OpenVPN will
give the remote client and you more "options" than using TightVNC with
stunnel, say. That may or may not be what you want, but it does
provide for greater flexibility.

hth,
prg
email above disabled

P Gentry wrote:
> Anthony Ewell <aewell@gbis.com> wrote in message news:<2opro7Fdcjj4U1@uni-berlin.de>...
> [snip]
>
>>Hi P.,
>>
>> I should have made it more clear that TightVNC has to
>>transverse OpenVPN to make connection with the other end.
>>I am presuming that OpenVPN will provide enough (encrypted)
>>security. Does this change your evaluation?
>
>
> IMO, for the average (and even above) scenario, it doesn't get much
> better than OpenVPN ;-)
>
>
>> As far as the floating IP's, I have complete control
>>over the firewall. I am a private contractor, not an
>>employee. My customer give me the final say on everything
>>to do with the network. They are dear people -- the ones
>>you want to take very, very good care of. Consequently, I
>>am very, very protective of them. I even have them off
>>of IE and OE (Firebird and Thunderbird are awesome).
>>They have only caught one virus in the seven years I have
>>worked for them! :-)
>>
>> As I stated before, floating IP's through the firewall
>>give me the hives. Since they give all of you the hives as well,
>>they are out. If the other users want VPN access, I will arrange
>>with their ISP's for a fixed address. (My other remote
>>users will love any excuse to upgrade to DSL at
>>their homes. So, it is a win-win situation for me!)
>>
>> I appreciate all of your wisdom and assistance in
>>this matter. :-)
>>
>>--Tony
>
>
> OK, you're already far down the road to setting up a secure solution
> via OpenVPN ;-)
>
> This setup is about as secure as you can reasonably get and will not
> _require_ static IPs for the remote clients -- all authentication is
> user based, not host based. That's the nice benefit of SSL/TLS
> encryption/authentication ;-)
>
> The biggest hassle is the initial setup -- to be expected -- and the
> "ongoing" certificate management. For a reasonably small office this
> shouldn't be too bad.
>

My major concern is theft of the laptop, the key being on
it and all. To cope with this, I am using the password feature
on OpenVPN. (The user is well trained to keep the password
seperated from the laptop. The password is also one of
those "nasty" ones, no guessing will break it.)

The idea behind a fixed IP is that a thief would
have to have that exact IP to break in. This would presume he
managed to somehow get the password, as in looking over my
user's shoulder when he is entering it -- most thefts are
from someone you would recognize.

If I was to have IPTABLES allow all VPN IP traffic in, I would
be defeating this safe guard.

But, I may be going to extremes. What is your opinion?

> The setup on your end should give you some idea what sort of
> problems/questions the clients will have when first using the service
> -- after a few goes most people have a good enough grasp to make it
> work just fine ;-)
>
> One nice thing I noticed about the the 2.0.x (still beta) version is
> the scalabilty -- the code layering is much improved. And a benfit
> for you and your client is that cert revocation will allow you to
> disenable a user's cert wehnever the need arises.
>
> Try this for a quick/concise overview of the security features then go
> on from there:
> http://www.inyotech.com/vpn_infrastructure.php
> the OpenVPN site has lots of goodies.
>
> Also check the net/Google to find some examples of people using
> OpenVPN to tunnel TightVNC -- best to know beforehand before
> travleling to far down that road. And keep in mind that OpenVPN will
> give the remote client and you more "options" than using TightVNC with
> stunnel, say. That may or may not be what you want, but it does
> provide for greater flexibility.
>
> hth,
> prg
> email above disabled
>


--
-------------------------
I Fish. Therefore, I am.
-------------------------

Anthony Ewell <aewell@gbis.com> wrote in message news:<2oshhkFcmnngU1@uni-berlin.de>...
> P Gentry wrote:
> > Anthony Ewell <aewell@gbis.com> wrote in message news:<2opro7Fdcjj4U1@uni-berlin.de>...
> > [snip]
>
> My major concern is theft of the laptop, the key being on
> it and all. To cope with this, I am using the password feature
> on OpenVPN. (The user is well trained to keep the password
> seperated from the laptop. The password is also one of
> those "nasty" ones, no guessing will break it.)

So long as users readily accept your security protocols, every layer
helps, IMO. It's when you get too "strict" that some bozo will start
trying to circumvent your setup -- but it sounds like you have a nice
group to work with ;-)

> The idea behind a fixed IP is that a thief would
> have to have that exact IP to break in. This would presume he
> managed to somehow get the password, as in looking over my
> user's shoulder when he is entering it -- most thefts are
> from someone you would recognize.

Like your concern about stolen laptops, stolen passwords are a real
(if hard to quantify) risk. If you don't plan for it ... :-(

> If I was to have IPTABLES allow all VPN IP traffic in, I would
> be defeating this safe guard.
>
> But, I may be going to extremes. What is your opinion?

This is one of the nice things about certificate revocation -- it will
allow you to revoke authentiction credentials. Once revoked, they
can't be used to get in. As for "letting in" VPN traffic -- that is
what the VPN GW is meant to handle. If you only allow certain, fixed
IPs to make it _to_ the VPN GW are you sure you've gained that much?
Is it worth the inconvenience (if there is any for your group) of not
being able to get in from an "unknown" IP, eg., someone on the road?
Besides you'll still have to be concerned with IP spoofing/sequence #
attacks as well as maintaining the fw rules when someone moves, etc.
Point is that only you can assess the level of risk/work/errors you're
willing to take. There _is_no_ totally secure network -- never has
been, never will be.

Get as much security as you can as long as you're comfortable with it
_and_ your end users are comfortable and satisfied with it -- press
them too far and they will start hacking in or out "behind your back"
(and that is always the worst scenario).

hth,
prg
email above disabled