> -----Original Message----- > From: Colin Horsington [mailto:c.horsingtonat_private] > 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:45:38 PDT