Re: Best practices for internal/external servers

> We'll probably have to agree to disagree since I see the VPN (and I'm
talking
> IPSEC based VPN here) as being the more secure option.

I don't disagree that a VPN pipe can more securely carry traffic. No
argument there. I only disagree that it's the default 'best choice' when
upgrading from dial-up when only e-mail is the driving force.

> Your only objection to using VPN seems to be the risk of client compromise
> but you state you are willing to use VPNs in some circumstances.
> That doesn't make sense.

Of course it makes sense. A client machine compromised with a virus, trojan
or other such malware when presented with an IMAPS link can do little other
than damage mail or send spam. When presented with a VPN pipe directly into
the host network all manner of foolishness becomes possible. A simple real
world analogy is perhaps the difference between letting you drop a letter
through a door's mail slot versus giving you a set of house keys. Yes,
anyone else could come along and cram something problematic into the mail
box. But if nobody else has the house keys that's about the extent of the
risk. A poor analogy, of course, but reasonably comparative to the
situation here.

Likewise there are other complications that develop when VPN are used. Most
notably client routing complications. Nothing like wasting gobs of
bandwidth having the remote user tunnel into the VPN for resources back out
on the internet. As in, getting stuck surfing into the office VPN for web
pages not inside the office. VPN clients aren't quite as smart as one might
prefer when it comes to properly routing traffic based on the application.
This presents unexpected surprises when off-hours activities don't coincide
with employer wishes.

> The risk of client compromise will be there in all
> circumstances. However the number of clients which could be compromised
and
> could be used to attack the network is going to be very limited.
> On the otherhand the number of systems able to attack a buffer overflow
> vulnerability in IMAP is equal to the number of systems on the internet.
> (VPN is not so vulnerable since in order for any traffic to get through it
must
> have completed all phases of the IPSEC authentication).

Again, in theory there's validity to your point. But in the real world the
likelihood of a user's home machine being infested with malware such that
injecting itself into the VPN would cause harm is quite possible orders of
magnitude more dangerous than having IMAPS ports open and being monitored.
I don't disagree that an effectively and securely configured client machine
can quite properly make use of a VPN for this. I just don't see many of
those things out there in the real world, but hey, I've only been doing this
since 1979.

What're they really after here, just remote mail without dial-in or actual
access to LAN resources along with the mail? If it's the latter then it's
quite appropriate to consider the effort to setup VPNs. Along with the
learning curve involved.

Of course there's also the hassles of port blocking to be considered. Not
everyone's going to be on as open a network as either solution would
require. All too often links don't allow passing SMTP or VPN sessions.
Keeping a modem or two handy might prove to be a worthwhile idea...

> (I'm ignoring IMAP proxy solutions in the above comparison since I have no
> knowledge of such systems).

Heh, then perhaps something like a VPN into a DMZ that contained a proxy
securely connected to the real IMAP server. Best of both worlds then, eh?

-Bill Kearney

.

Relevant Pages

  • Re: Another RWW versus VPN question
    ... A Pix does not ...by itself make you more secure. ... VPN "can" make you more insecure. ... I have a client that recently had a programmer from a large security based ...
    (microsoft.public.windows.server.sbs)
  • [NEWS] Cisco VPN 5000 Client Multiple Vulnerabilities
    ... Multiple vulnerabilities exist in the Cisco Virtual Private Network (VPN) ... 5000 Client software. ... These vulnerabilities are documented as Cisco bug ID ... CSCdx17109 - MAC OS VPN 5000 Client password vulnerability ...
    (Securiteam)
  • Re: VPN clients unable to connect to other resources.
    ... gateway matches the IP of the remote client, and DNS and WINS point to the ... remote (although it takes close to a minute to connect, ... This is just regular Windows VPN, ... VPN server, remote routing and access running on the SBS 2003 server ...
    (microsoft.public.windows.server.sbs)
  • RE: Slow VPN logon and Spuratic folder visibility
    ... I understand that the remote VPN client ... network configuration. ... the VPN client can access SBS fine? ... Slow VPN logon and Spuratic folder visibility ...
    (microsoft.public.windows.server.sbs)
  • RE: VPN timeouts
    ... I do not use ISA & was wondering if there is a configurable option on the ... You remote clients VPN connection will timeout while trying to connect SBS ... between remote client and SBS server which caused by lack of network ...
    (microsoft.public.windows.server.sbs)
Loading