Hm. Thanks - this is the first thought provoking one for a while.
> -----Original Message-----
> From: Randall, Mark [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 26 November 1999 10:31 PM
> To: [EMAIL PROTECTED]
> Subject: Parallel pathways
> Importance: Low
>
>
> I've got a client that has two sites, [snip] They [snip]
> want to install a small VPN appliance from Compatible Systems
> at each site.
I do not know anything about this box. I assume from followup comments that
it's some sort of IPSec doover.
>
> The client has an architectural layout in mind, where the
> Compatible Systems
> VPN boxes will sit next to FW-1, using a completely separate,
> parallel path.
> They have fractional T1 service at each site and want to
> connect the router
> to a small hub. Then they want to connect FW-1 and the VPN
> box to the hub
> and provide dual, parallel pathways into their network.
I guess. It would be good to have a dual ethernet router, but hey. At least
this way you might be able to get an IDS that can see traffic destined for
both boxes one day, which could be a good thing.
>
> I don't like the idea of bypassing the firewall at all... I tried to
> explain that a pathway around the firewall sort of defeats
> the whole purpose
> of having the firewall in the first place, but the client
> insists this is
> the desired configuration. They feel safe in the security
> provided on the
> theory that the VPN box will not allow anything but
> authenticated VPN users
> and remote sites anyway, so it doesn't really pose a security risk.
I agree with the customer. Look at it this way - lots of places have a rack
of modems. There's a "common configuration" - and it absolutely sucks. Ask
anyone that's tried to secure and manage even a _small_ fleet of dialup
users and analog dial technology. At least this way there is only one box to
mess with and they can still use real authentication on all the dialup
users. In fact, I would consider it as strong or stronger than hardware
tokens with PIN numbers.[1]
> Have any of you setup such a configuration before? Is it
> really as common
> as this client would have me believe? As soon as I saw the
> drawing on the
> board, red flags went up like crazy. It just doesn't look right at
> all...but I wanted to ask for opinions and/or comments here.
I'm not convinced by this "common == good" argument. This may sound like a
specious comment, but my point is that we should really be assessing each
solution on their merits - VPNs and "extranets" are already doing a good job
of changing the traditional points of access / attack on networks, so a
flexible approach is important. Mind you I also respect the point of view
that says new solutions are untrusted until proven trusted. 8)
As I said, I can't comment on this particular solution - this Compatible
Systems box might have some backdoor where anyone can authenticate using
"root" with "31337" as the password for all I know. However, if it's done
right I can't think of any reasons why this _design_ should be less secure
than using the one box for firewalling and VPN traffic. And in its favour,
it's probably easier to write a secure IPSec appliance than it is to write a
secure firewall. I'd also be looking for some hardware crypto assistance if
I was implementing high speed inter-site links as well as terminating lots
of dialin sessions. The performance argument may be enough to mandate a
separate box in some sites.
Anyway. Enough waffle.
Cheers,
[1] From a later email I note that laptop users will be using an IPSec
client to connect to this VPN appliance. I would therefore assume that each
user will be given a digital certificate from a real CA to prove their
identity when dialing in. Then, (for example) use the latest version of PGP
to create a PGP disk that secures their certificate. On boot, the user will
have to enter their passphrase to mount the disk. This prevents someone
stealing the laptop and having everything they need to authenticate. This
may be _more_ secure than hardware tokens and PINs (excluding OOB attacks -
attacks that _circumvent_ the auth process) because it doesn't rely on a
pseudo-random sequence and because the "something you know" bit (the PIN or
the passphrase) is longer and more memorable.
--
Ben Nagy
Network Consultant, CPM&S Group of Companies
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
