Firewall @ remote location

[Eric Henriksen]

You may also consider one of the appliances that offer a combo firewall/vpn
gateway, terminating the inside of the vpn server in the firewall.  With
this, you can ont only fliter, but also launch user authentication.

Otherwise, you may consider running the client or vpn gateway such that all
traffic is tunneled over the vpn when it is active.  This would eliminate
the possiblity that the remote machine could get hijacked WHILE the vpn is
connected to the head end.  Access to the internet could be accommodated via
the internal side of the corporate firewall as the default gateway for the
corporate VPN server, and override the route for the vpns to go directly out
the pbulic interface.

This way, the user is able to DNS resolve and access the public internet
transparently whether the vpn is up or down, minimizing phone calls or DNS
copmlexities.  This not only plugs a security hole, but puts the
authorization and autidting back in the hands of the HQ staff, if a bit
Orwelian.  Also, if the user has a 'need for speed' they'll likely call, and
be willing to take the extra step recommended by their support people to
shutdown the vpn if they want to browse the web directly.  However, with DSL
connections and a fair (T1 or better) HQ link, they may be none the wiser.

I recommend going the extra step with the latter config and have it launch a
RADIUS/token/cert challenge for the USERs of the remote vpn gateway/client
software.  Even if you can keep the MIM (man in the middle) attacks to a
minimum, you should still not assume the identity of the remote user unless
the facility is access controlled with the same trust level as the HQ side.

Another step is to avoid statically assigning the virtual ip address to the
remote clients, as these can be gleaned from the machine when it is browsing
the web directly and used to constructy a subsequent attack when the tunnel
is up.  Instead, use a private DHCP server to offer these up dynamically
only when the tunnel is up, releasing them when the tunnel goes down.

Not all vpn servers are capable of doing this, but I can attest that
RedCreek's products can.

Eric
----- Original Message -----
From: Brad Kemp <kemp at indusriver.com>
To: Danilo Dessi <ddessi at ibm.net>; <vpn at listserv.secnetgroup.com>
Sent: Thursday, October 28, 1999 2:23 PM
Subject: Re: Firewall @ remote location


> A VPN extends the network perimeter.  Therefore you have to take
> the same precautions on a client that you would on a corporate host
> exposed to the internet.
> A couple of recommendations:
> Do not run unessecary services (web server, ftp server....) on the remote
> host.
> If the remote site's OS is NT, remove the WINS binding from the
> DSL adapter. This will stop Microsoft SMB traffic from reaching your host.
> Run Virus protection on the remote site religiously.
>
> There are 'personal firewall' vendors out there that will sell you
> a firewall that co-exists with your remote PC.
> conceal http://www.candc1.com/conseal/
> digital robotics http://www.digitalrobotics.com/fire.htm
> and many others.  A web search on personal firewall should find most of
them.
> Brad
>
> At 07:17 PM 10/26/99 -0400, Danilo Dessi wrote:
> >>>>
> I am planning a "VPN" to connect a bank's head office with a small rep.
> office.  My question regards firewalls.  Since there will only be one
> computer at the rep office it is very hard to justify a firewall which can
> cost more than the computer.  The rep office will have a DSL connection to
> the Internet. I would like to know if there are other considerations other
> than the fact that the line is always up why I should have a firewall at
> the remote location.  In other words is there more risk (exposure to
> hackers) at the rep office compared with a telecommuter who dials up from
a
>  remote connection and then hangs-up when he/she is finished working?  Can
> a hacker actually gain access to the head office LAN by comprimising the
> computer located at the rep. office?
>
> Thank you to all replies,
>
> Danilo
>
> <<<<
>
>
> --- -- --
> Brad Kemp
> Indus River Networks, Inc.                   BradKemp at indusriver.com
> 31 Nagog Park 978-266-8122
> Acton, MA 01720                              fax 978-266-8111
>
> ****************************************************************
> TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com
>
> The VPN FAQ (under construction) is available at
> http://kubarb.phsx.ukans.edu/~tbird/vpn/FAQ.html
>
> We are currently experiencing "unsubscribe" difficulties.  If you
> wish to unsubscribe, please send a message containing the single line
> "unsubscribe vpn your-e-mail-address" to
owner-vpn at listserv.secnetgroup.com
>
> ****************************************************************
>

****************************************************************
TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com

The VPN FAQ (under construction) is available at
http://kubarb.phsx.ukans.edu/~tbird/vpn/FAQ.html

We are currently experiencing "unsubscribe" difficulties.  If you
wish to unsubscribe, please send a message containing the single line
"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com

****************************************************************