Firewall @ remote location

[Misha]

I am a little confused about the part where you mention that "DSL routers
are terribly insecure". Unless you are referring to a firewall feaure set
of any particular DSL box, I don't see how you can expect them to be
otherwise secure. If you don't run anything as basic as packet filtering
on the DSL router, then any vulnerability you refer to is simply related
to the OS. I am sure you are refering to something other than just plain
vanilla DSL router of course, coming from iprg.nokia.com:)

You also have to be quite careful about how DSL is configured. I have seen
some ISP' who run nothing but bridged connections and often get the same
problems as cable modem providers. The bridged DSL connections we provide
(I work for an ISP) don't allow broadcasts to other PVC's (all clients get
their own PVC), for most VPN applications we suggest SDSL service which we
offer as a routed option only with a dedicated PVC per each endpoint. 

Larger clients can even afford more advanced types of DSL service, where
the options are:

1) Drop off the DSL switch (Redback, Cisco) at the main datacenter, bring
up an ATM circuit to a DSL carrier (Covad, Northpoint, skip the Bell's)
and run the PVC's from all DSL clients directly into the clients network.
Along with any IP VPN flavor (usually IPSec) this gives you quite a nice
configuration, with Layer 2 and 3 security. PVC's can either be
authenticated against a Radius database for additional flexibility. This
also allows you to bypass any problems with managing security on the
remote client end, because they never really hit the public IP network
until they use the coporate firewall, which allows you to enforce your
security policy universally. No ISP's required, though you may want to use
their services for deployment and management. Not really an option for
small or medium sized clients.

2) Allow the ISP to terminate the DSL PVC's (yes I am talking about ATM
btw). Bring up an ATM connection to an ATM enabled router at the clients
side and handoff the ATM traffic, which still have more management than
usually offered at Layer 2, along with IP based encryption at Layer 3. All
remote clients still have to get IP through the corporate firewall, though
you loose the benefit of knowing that the PVC's never touch the ISP's
equipment.

3) Do the most basic thing most ISP's could do and provide the PVC and
IP. In this case you are faced with bringing up IP based encryption and
enforcing the security policy through something as lame as personal
firewalls. Personally I would probably look at something like Network Ice
as an alternative. 

Do your homework with your ISP. DSL may be a great choice for any
application other than mobile users. Most carriers offer a national
option, and some even offer it to the ISP's for free (Covad does), so you
may be able to get all the remote branches connected through the same ISP.

Misha




On Sat, 30 Oct 1999, Kelly Robertson wrote:

> Danilo,
> 
> 
> The answer for me is that DSL routers are terribly insecure and the
> typical client computing environments are no better. I ran basic recon
> probes and attacks against my own DSL router and SOHO and had two
> colleagues do the same. We were all successful in breaching my DSL
> Router. I had Linux, Free BSD, NT, 98, and 95 behind the router and got a
> lot further with all of them than I care to tell. 
> 
> 
> DSL is nailed up all of the time and therefore vulnerable to scans. I
> would look to VPNet, Netscreen, or perhaps others for solutions under
> $1,000. End user machines can be hardened in many ways as well, without a
> lot of cost. Since my tests showed vulnerabilities that did not require
> an expert knowledge to exploit, I needed to take reasonable measures. One
> thing, for example, is that I now use PGP disk on every box with
> sensitive data on it. I have it configured to shut down any virtual disk
> after five minutes of inactivity. This in itself does not constitute a
> secure environment, as it only assures the confidentiality of my
> information when I am not using it, but it is a layer of security that
> begins to give me assurance. 
> 
> 
> As for the cost of the solution and the cost of the computer, I find this
> to be a fallacious comparison, frankly. I would recommend to my customer
> that they quantify the value of their data, not the value of the pc, and
> take reasonable precautions to protect it. A $1,000 solution seems
> reasonable for a financial institution, in my humble opinion, even if
> they are rolling out 2,000 kiosks...
> 
> 
> As for whether there is a path to the corporate LAN from the <<assumedly>
> compromised machine in the field, there is indeed reason for concern on
> your part. This is relative to the trust level between machines, which
> any skript kiddey with time and some tools can exploit.
> 
> 
> Reasonable precautions with a reasonable budget work well. Let common
> sense prevail over the bean counters...
> 
> 
> <<2 cents for nothing>
> 
> 
> Kelly Robertson
> 
> 
> 
> 
> At 07:17 PM 10/26/99 -0400, Danilo Dessi wrote: 
> 
> >>>>
> 
> <excerpt><fontfamily><param>Arial</param><smaller>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?
> 
> </smaller></fontfamily>  
> 
> <fontfamily><param>Arial</param><smaller>Thank you to all replies,
> 
> </smaller></fontfamily>  
> 
> <fontfamily><param>Arial</param><smaller>Danilo </smaller></fontfamily> 
> 
> 
> </excerpt><<<<<<<<
> 
> 
> 
> ****************************************************************
> 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

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