Re: [fw-wiz] Secure access to LAN resources (WAS: terminal services)

From: Paul D. Robertson (proberts@patriot.net)
Date: 01/28/03


From: "Paul D. Robertson" <proberts@patriot.net>
To: "Behm, Jeffrey L." <BehmJL@bvsg.com>
Date: Tue Jan 28 17:02:02 2003

On Tue, 28 Jan 2003, Behm, Jeffrey L. wrote:

> Hi Paul,
>
> On Tue, 28 Jan 2003 proberts@patriot.net wrote:
>
> > On Tue, 28 Jan 2003 natfirewall@netscape.net wrote:
> > > Greetings,
> > >
> > > I am being asked to open port 3389 on our Corporate firewall and
> > > direct incoming traffic on that port to a specific IP on
> > our internal
> > > network. Being the paranoid that I am, I do not want to do
> > this but I
> >
> > I wouldn't do that for any money.
>
> I thought everyone had a "price." ;-)

I'd hope that there are still people around who can't be bought- if not,
we're in bad, bad shape! When you work with great stalwarts of behaviour
and ethics like Bill Murray, you're constantly reminded of what nice
people don't do ;)

> Wouldn't having a VPN simply _move_ the DoS to another machine/system, not
> protect against it? My understanding is that VPN protects the data via
> encrypted tunnel. Just because the data is encrypted doesn't imply it is
> _desirable._ I suppose if you limit who can talk in the tunnel, then that
> would help...is that what you are getting at?

Yes, VPN devices are designed to do strong authentication. What I left
unsaid (but was covered by another poster) is that you must couple it with
strong authentication. Also, VPN devices are designed to be placed
outside firewalls, Terminal Server really isn't. While that's no
guarantee it'll be safe, it sure helps. Finally, you can pick a VPN
server based on security- other than possibly going to Citrix, you're
pretty much stuck with a single-vendor solution with TS.

> While on this subject, but down a different and more general tangent...
> Any opinions/gotcha's/don't do's/do do's <-yuck/etc. on using
> products/appliances such as Aventail or Neoteris as a _secure_ way to allow
> employees and/or external clients/partners into resources on your LAN? These
> devices supposedly create a VPN tunnel using SSL for encryption, which is
> allowed out through most companies firewalls and allows the outsider to
> connect to this DMZ appliance which, in turn, allows/denies access to LAN
> resources based on authenticated users and the rulesets configured by the
> admin.

The more you can limit who connects, the less likely you'll get a bad
connection. The stronger your authentication, the less likely someone
will be able to compromise an ID and password (I'd almost always want
hard physical token-based authentication.)

> (Aside: This may help lessen the support calls but opens up other issues,
> such as "Does the other company know their computers are being connected to
> your company's LAN? I.E. What are the legal and/or ethical ramifications?)

If you're tunneling it via HTTPS, then there certainly are ethical
ramifications, and most likely legal ones if their usage policies are
well-written.

> Is there such a thing as _secure_ access to LAN resources over the Internet?

Nuke "over the Internet..."

It's always a trade-off between risk and protection. The real question
*shouldn't* be "Is it secure" because that gets us into religious stuff
too quickly, it's "can I mitigate the risk well enough to make it
worth-while." It's difficult for us security geeks to find that line (as
an aside, I chose my title just to keep reminding me of the fact that it's
a risk decision, not a security decision.)

For most of us, the risk of opening a port to a device on the internal
network without some sort of arbitration is too large, we can mitigate
that risk by adding some sort of gateway that takes care of some of the
issues.

Your questions on the ethics and legality are very good ones. How many
places even make visitors adhere to usage policies? How many cover
tunneling? How many educate their users to ask if it's ok?

Certainly, that's a discussion I'm willing to have on the list- I think
it's important that people think about these things.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts@patriot.net which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation



Relevant Pages

  • Re: Site-tosite VPN Issue
    ... > we have seen many slow issue on DSL VPN. ... >> Authentication of local users off, ... All four PCs at the Remote Office authenticate ... >> tunnel to the domain controller and the domain controller is yet the ...
    (microsoft.public.windows.server.networking)
  • Re: VPN versus Terminal Server for remote workers
    ... If one wants to cross the river and gets into a secure tunnel, ... this does not really help me understand why the hardware will allow ... By default and intention 'split tunneling' of VPN connections is not ... as far as using Term Server, the question really is: ...
    (microsoft.public.windows.server.sbs)
  • Re: RV042 - Does anyone understand it? Documentation?
    ... if one is using an RV042 for VPN, then what affect does the routing table have on the VPN packets? ... When the packet is received at the other end of the tunnel, it will still be destined for a "foreign" private subnet. ... In other words the range of IP's you are trying to reach and the range of IP's the traffic is coming from MUST be included in the subnets for the encrypted tunnel. ...
    (comp.dcom.vpn)
  • Re: Best practices for internal/external servers
    ... >less of a security risk than does an inbound VPN. ... >> anyone anywhere in the world to attempt to attack the IMAP server. ... Then if a client machine is compromised the only thing it'll be ...
    (comp.mail.imap)
  • Re: [fw-wiz] VPN endpoints
    ... > 1) Some VPN products default to allowing the Null encryption algorithm. ... The cost of compromise is a function of the risk that the data may be ... > most of the benefits are in the fact that practically any client can be ...
    (Firewall-Wizards)