[SunRescue] The fallacy of frame relay security OT:VPN WAN's

[Brian Dunbar]

Christopher;

Thank you for sharing your thoughts on this subject - I'm (as I said) by no
means a subject matter expert - I tried to have   my business card read
"jack of all trades, master of none" but corporate didn't like that - and
any information is helpful. 

It was easy to forget that our frame relay traffic is carried on the same
circuit as other peoples - I say WAS as a bum router on San Francisco
belonging to AT&T crippled our DNS service last Friday/Saturday.

I'll stand by my intuition on the final costs (which, for good or ill are
what the VPs see) in that a frame relay, all things considered will at least
be as cost effective as a VPN solution . . but I'd love to see any hard
numbers on that issue.  

Anyone?

Brian

-----Original Message-----
From: Christopher Byrne [mailto:chris at chrisbyrne.com]
Sent: Saturday, February 10, 2001 1:20 PM
To: rescue at sunhelp.org
Subject: [SunRescue] The fallacy of frame relay security OT:VPN WAN's


Brian,

One thing you must remember about so called "dedicated circuits" or "leased
lines" is that they are by no means dedicated. The only point at which you
are not sharing bandwidth with other users is from your buliding to the
central switching office, or centrex site, which is of course the same as a
feed to the public internet.

Once your traffic has reached the central switching office it is multiplexed
with other frame relay customers. It is then forwarded to a major access
node and multiplexed over the long haul connections that also carry traffic
for the public internet. It goes through the same switches and routers in
most cases as does the public internet. The only real seperation of your
supposedly private traffic from the internet is the good graces of the
routers within the path of the PVC or SVC.
This is often referred to by the telcos as the "Frame cloud" as if ti were
some special seperate tecnology or infrastructure, when, in the main, it is
not.

In fact, since PVC's generally use persistent routes, it can actually be
easier to set up a long term data capture through the compromise of a single
en-route router, whereas with public infrastructure networks, which use
inconsistent multipath routing it can be more difficult to do so.

Several years ago I demonstrated this for some telco people by using the
RMON capabilites of a router in the frame cloud to set up a massive data
capture. My team compromised the router quite easily (they had left some
default passwords) and configured data capture within a few minutes. We saw
that there was already a significant amount of RMON and SNMP data going
through the system, and decided that would be the best way of montioring the
device. So for the next week we would poll in 60 second intervals the RMON
agent, and recieve all of the traffic that passed through the router.

The data capture was not detected, and at the end of the week I presented
the telco folks with several gigabytes worth of captured passwords, email,
etc...

Had we wished we could have easily redirected traffic through my site,
giving me even greater abilities to either capture or manipulate the data.
All of this was on supposedly secure frame relay traffic.

This is not to say that I consider the internet to be more secure than a
frame circuit, I do not, simply that the idea of a frame relay network being
secure is basically untrue. This leads to the cliche'd "false sense of
security" and people send traffic across these secrets that they otherwise
would not.

I'll give you a basic example (the names have been changed to protect the
guilty)
A major financial institution managed it's systems using HP Openview, an
SNMP management platform. They also used a software package called Network
Health to provide for capacity planning, historical trending and the like.
Their office to office links were all frame relay.

Some months after their final installation they started seeing holes in
their Net health data, even though openview was operating fine. The reason
was really quite simple, and quite frightening. Another network health user
was polling their objects at the same time as they were, and their snmp
requests were timing out. This other company was serviced by the same frame
relay provider, and because of mis-configuration there was some
communicataive traffic across the networks.

This sort of thing happens quite frequently. My personal philosophy is
simple, once it leaves your building it is insecure. It can be made more
secure through encryption, but frame relay is simply another access
technology with little if any security advantage to it.

The primary advantage of frame relay is the guaranteed level of service, and
consistent latencies. These are things that can be planned for, and as you
say efficiently dealt with by a single point of contact. But please, if you
want your data to be (more)secure, it must be encrypted.

Christopher Byrne
Founder, Secure Defense Solutions
CCSA CCSE CCSI NSA NSI MCNS MCSE


-----Original Message-----
From: rescue-admin at sunhelp.org [mailto:rescue-admin at sunhelp.org]On
Behalf Of Brian Dunbar
Sent: Friday, February 09, 2001 07:35
To: 'rescue at sunhelp.org'
Subject: RE: [SunRescue] OT:VPN WAN's


I'm not a security or VPN or WAN expert, but I've dabbled in all 3.  Having
said that;

Using the public net as a transport for your critical IS stuff seems fraught
with .. not danger, perhaps, but a bit of risk.  There isn't any one person
you can go to if MAE West is not sending your packets on,  or if things just
seem a bit slow.  If you spend the money on a frame relay, you have one
vendor, and a dedicated circuit.

I dunno, but from dealing with the decision makers at my company, I'd bet
that your guys gulped at the cost of the frame relay, and decided that if
each site/business unit pays for the cost of their own ISP and connection,
it eases the cost a bit.  My intuition is that the cost of 200 sites paying
for their own connection, plus associated hassle, equals or exceeds the cost
of a frame relay circuit.

Had you considered an alternate, like yipes!?  They run Ethernet over fiber,
costs seem comparable.

brian


_______________________________________________
Rescue maillist  -  Rescue at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/rescue