RE: secure remote access and firewalls

[Ben Nagy <bnagy () cpms com au>]

> -----Original Message-----
> From: Colin Horsington [mailto:c.horsington () aas com au]
> Sent: Wednesday, 27 October 1999 9:34 AM
> To: Firewall-Wizards (E-mail)
> Subject: secure remote access and firewalls
>
>
> Dear Firewall-users
>
> Recently their has been a requirement to link up securely some remote
> branches. To do this it has been proposed to use firewalls 
> not to do VPN in
> the strict sense of the word, but to implement packet 
> filtering effects to
> limit access to the remote machines.

So this isn't really any sort of "linking up", it's just messing with access
control...

[snip]
[ASCII death also snipped]

> Does this have any security implications besides un-encrypted packets
> travelling over the public network. 

No encryption is the worst. In theory you're vulnerable to spoofed source IP
addresses from the world at large. However, it's very difficult for anyone
to use this to attack the site other than denial of service of another
method that doesn't require that they get any packets back. If you are
running fragile hosts then this may cause you some problems. Also if you
don't trust your upstream carrier - they're the point where people could
mount realistic IP spoofing attacks to impersonate one of your remote sites.

If you don't care about the data that is being ferried back and forwards,
then I'd say go ahead and do the access list thing. You can always use some
application layer encryption / authentication if you need to send the
marketing database. If data is being routinely transferred that you care
about, look at VPNs.

> If so what other methods 
> could be used
> considering every branch does not want to change it's current 
> infrastrucure
> much, and does not want to have to use a specific firewall 
> for firewall A
> nor chnage what they have, and firewall B may also be a 
> different box at
> every location!

Use something interoperable like IPSec? I think the current versions of most
of the major firewalls support it...You can do all the IPSec stuff between
gateways without any real impact on the clients. Read the archives for
limitations of IPSec with NAT, but, in summary, it will work, but might
screw dialin users that want to connect to the VPN via the Internet at
large.

> Also if a 'VPN' were to be used how could one be setup 
> between all branches
> as one vpn, rather than having nxn (n squared) vpn's.

n^2 would be weird. If we're assuming that by 'VPN' you mean 'tunnel between
two sites' then the worst you could get is (n-1)^2, I think. This would be
for unidirectional connections. However even if you use pre-shared keys,
you'll probably end up with something more like (n*(n-1))/2 keypairs which
is about half the number you were looking at.

To keep it down to n VPNs you could route every connection through the
central site, but this is a bit ugly and imposes unneccesary delay. If you
were using IPSec for four remote sites I would possibly just use pre-shared
keys - it's only 10 keypairs. If you're getting much bigger then I'd look at
using PKI to manage the authentication. Get a certificate for each site and
have the site that's being connected to verify that the certificate checks
out. Now you only have to manage n certificates. More overhead to set up
though.

> Kind regards,
>
> Colin Horsington

Cheers,

--
Ben Nagy
Network Consultant, CPM&S Group of Companies
PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520