vBNS Security Hints

This document is not meant to be a "How to" secure your vBNS site. It is intended to give you an idea of what others are doing to secure their sites. It is broken into three sections:

Common Questions

Common Protection Mechanisms

Other Sites with Security Information

Common Questions:

1) Why is vBNS security different from my regular internet connection?

What presents the vBNS with a unique challenge is that implementing some forms of security, such as a firewall, will likely slow down what you're trying to run at full speed.

2) Why should the vBNS be of any special concern?

The vBNS will most likely operate at OC-3 speed and a ping attack at that speed could be devastating to your campus. That's just one small example.

3) What security threats does the vBNS pose?

The vBNS is an external connection to your campus, and poses the same security risks as any other connection would. If you have specific security concerns which you address on your Internet connections, you probably need to address the same concerns with your vBNS connection. This document might be helpful in doing this.

4) Does the vBNS pose any unique security threats?

Not really. There is some increased threat of "denial of service" attacks, which, if they originate from other vBNS sites, could take advantage of the higher bandwidth. Eventually, there may also be new vulnerabilities which open up, associated with the new applications and services offered on the vBNS.

5) Do the administrators of the vBNS (MCI) have any security tips?

Try MCI's security web page at: www.security.mci.net

What are common ways for me to protect my campus?

Firewalls

Monitoring ATM connections

Authentication/Encryption

Host Security

Routing choices

Web Caching Security

Firewalls:

As of the writing of this hint sheet, there is only one company actively selling a ATM/IP Firewall solution. That company is Network Systems Group and the product is called ATLAS. I don't have any experience with the product and I would welcome any opinions as to whether the product lives up to its potential.

A network administrator might be able to roll their own Firewall solution by using a multi-homed unix box Firewall. In theory, if you purchase a workstation/PC that is extremely fast and has a fast system bus that can sustain, at a minimum, 2 OC-3 ATM cards, chances are you can build a suitable Firewall system. The bottleneck is not only having 2 OC-3 ATM cards, but:

converting ATM cells into IP packets and then reversing the process;
firewalling raw ATM packets.

The Pittsburgh Supercomputing Center is beginning to work on a "roll our own" ATM Firewall using a fast Digital Alpha Workstation and 2 OC-3 cards. We believe that Suns Ultras are also up to the task but do not have any to experiment with. This is not an endorsement of either product.

If you have a T-3 running to your site, there are several good options such as the Cisco PIX firewall system. We asked the Cicso manager of the PIX firewall on 9/18/97 about a OC-3 PIX firewall, and his reply was "we don't have active development underway today." Another "roll your own" system would be to purchase a high-end PC, a PCI HSSI card from SDL Communications and run your favorite Firewall software.

Monitoring ATM connections:

MCI has given the user community a very valuable tool, OC3mon. By using this tool, you can examine, after the fact, what a potential intruder might have attempted trying to break into your site. OC3mon only captures the first cell of a flow so you will have the IP header, but no payload. In the next version, 3 cells will be captured so you can examine IPv6 packet headers.

Authentication/Encryption:

One of the most popular methods today of authenticating users is the system developed by MIT called
Kerberos. Kerberos is (from the Kerberos FAQ) :

Kerberos is a network authentication system for use on physically insecure networks, based on the key distribution model presented by Needham and Schroeder.[3] It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. It also provides for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptography systems such as DES. Many universities are using Kerberos V5 to do their authentication and encryption. The main limitation of Kerberos is in the administration of it.

Some colleges are using another system called SmartGate which is being sold by V-ONE. Florida State is currently using the product for their campus. One nice feature is that they sell a floppy disk thats actually a smart card used for encryption/authentication.

Although the cost might be prohibitive, SecureID is another alternative for smart-card authentication.

SSH & SSL provide encryption of transmissions at the transport and application layer, but at a cost in performance.

Host Security:

I believe that host security is the most important aspect of security. If you leave your internal security weak, someone may break in and use your site to launch attacks at other sites. One of the best methods to keep your site safe is to subscribe to the CERT mailing list for bug reports. The unofficial list to subscribe to is called BUGTRAQ (I don't have any pointers to it currently). Bugs (and many times the fixes) are posted to this list.

Some places to look for patches:

SGI
SUN (and do a search for patches)
HP (and do a search for patches)
AIX

If you have more links to add, please send me email!

Routing Choices:

You can limit the vulnerability of your hosts by limiting the address blocks that you announce to the vBNS. Since the number of routes on the vBNS is nowhere near the number of routes that the commodity internet has, it should be no problem to announce /24s. You may also want to consider turning off source routing through your router/firewall.

Web Caching Security:

Since a Web Caching machine is recommended for sites on the vBNS, security of these computers is vital as they will be outside of your firewall. Our suggestion is to turn off everything that can respond, such as telnet, rcommands, etc. You can replace it with ssh (with tcp wrappers compiled in) to make sure that there are no unauthorized attempts to connect to your cache.

If you have any suggestions/comment/additions/subtractions please email me at lappa@psc.edu.

© Pittsburgh Supercomputing Center (PSC)
Revised: September 1997
URL: http://www.psc.edu/networking/nlanr/faq/Security.FAQ.html