Virtual Private Networks One way to get through the firewall NCAR’s VPN Experience Jeff Custard Westnet 14-Feb-2001

NCAR’s security perimeter Who is inside? Most users on UCAR campuses Dial-in users connecting to UCAR dialups Who is outside? Users at UCAR divisions that have elected to remain outside the perimeter Dial-in users connecting to external ISPs Anyone else on the Internet at large

NCAR VPN Solution A conceptual diagram of what we wanted to achieve

NCAR’s VPN devices Cisco VPN Concentrator 3015 PowerPC equipped, software based VPN gateway 100 simultaneous users (unlimited client license) 4 Mbps aggregate traffic Expandable with the addition of Scalable Encryption Processors (SEP) with capacity for 1500 simultaneous users and 50 Mbps throughput. We purchased the upgradeable version of this product so it could scale if needed Cisco VPN Concentrator 3015 (from the Altiga acquisition)

The Linux solution Dedicated box Penguin Computing Linux server 500MHz Celeron/256MB RAM 2 x 10/100 NICs FreeS/WAN v.1.8

NCAR’s VPN client solutions Windows Cisco IPSec client Linux FreeS/WAN Macintosh and Solaris No current solution Cisco client solution coming 3/2001 (Cisco’s VPN 5000 series supports them now)

Windows VPN solution 2 Cisco IPSec client flavors W95 through WNT4.0 Windows 2000 (beta version available now because we participated in the beta testing program—NON-beta version due out 3/2001)

Windows VPN solution Cisco IPSec client Establishes IPSec tunnel to Cisco VPN Concentrator 3015 (and closes off all other network access when enabled) We use a group ID and password to establish tunnel (can also use certificates) We then validate the user on their UCAR “gatekeeper password” via RADIUS The IPSec group determines how you access and use the remote network. For example, it specifies access hours, number of simultaneous logins, user authentication method, and the IPSec algorithms your VPN Client uses. These parameters are set by the VPN administrator.

Windows client issues Why not use PPTP? Leaves other PC connectivity open (the Cisco client disables all other access) Must be administrator to install on NT and W2K Client configuration issues 3015 can automatically send DNS, WINS, gateway, etc., settings to client (our setup requires users to enter their appropriate WINS settings) Must control the distribution of the Cisco IPSec client Q: I have a Windows 2000 system and it has Microsoft PPTP VPN software built in. Why can't I just use that? A: UCAR's security policies require that any system that is connected to our internal network (which includes via a VPN link) and is also connected to an external network implement access restrictions. PPTP does not implement these restrictions and is thus deemed unsafe to use to connect to UCAR. PPTP, which has been banned by CSAC because it leaves the machine at the remote end of the VPN wide open to the rest of the Internet, has officially been disabled on the VPN box. Q: How are nodes or networks connected to the UCAR internal network via a VPN connection treated as far as CSAC is concerned? A: CSAC has approved a clarification to the External Network Connectivity policy that will explicitly treat nodes or networks connected to the UCAR internal network via a VPN the same as fully exposed hosts that are directly connected to the UCAR internal network. This means those hosts must follow the exposed host security standards to avoid becoming a back door around our security filters. The immediate consequence of this is that the PPTP protocol on Windows machines cannot be used for VPNs, because it does not disable other connectivity to the machine and NetBIOS file sharing is not allowed on exposed hosts (a PPTP VPN with NetBIOS turned off is seen as being too difficult for the average user and of limited usefulness anyway; there is little point in setting up a VPN if you can't do file sharing). The Cisco VPN client is acceptable under this policy because it completely shuts down all local network connectivity to the machine while the VPN is active, which is more than sufficient to meet the exposed host security standards. It was felt, however, that having hosts with NetBIOS running that is exposed to a foreign network while VPN connected to UCAR is simply too unsafe. There are canned hacking tools out there that will permit script kiddies to take over any machine with an exposed NetBIOS service.

Legal issues Cisco VPN client issues From the legal point of view, we have four classes of users: UCAR employees who install the software onsite UCAR employees who download the software to their home systems Remote users within the US Remote users outside the US Categories 1-3 are not a problem as long as we take "reasonable precautions" (defined in the legal sense) to make sure that the person we are giving the software to is really who they claim to be, really fits within the designated category, and that this person does not make the software available to anyone they are not supposed to. Category 4 requires an export license (which we are not going to get, so foreign users have no "clean" solution for the time being unless they can find a way to obtain the Cisco VPN client software other than from us) We did receive a green light from UCAR Legal to distribute the Cisco VPN client software based on authentication of a UCAR employee's gatekeeper password only. If the user can prove in this manner that they are a UCAR employee, that is considered legally sufficient to prove that they are within the US, and we would not have to run any additional checks against their point of origin nor would the user have to certify anything, which means a more-or-less ordinary FTP download could be used. This means we could implement something like a class of FTP users (in the wu-ftpd sense) that can authenticate with their own gatekeeper passwords, and then have access to the VPN software. Unfortunately, since some users with valid gatekeeper passwords are not employees (and are in fact foreigners), it won't be as simple as using a standard gatekeeper authentication module, it will require an additional check of the user name against a list of users that are known to be local employees. Such a list could be obtained from the online NCAR phone book, so there is at least some chance of automating this whole process.

Linux VPN solution FreeS/WAN (www.freeswan.org) Known to work with Linux and BSD Must recompile the kernel Linux client must comply with CSAC security standards for fully exposed hosts (disabling services or using ipchains to block access; IP firewalling must be enabled in the kernel) Q: What do I have to do to be sure that I am in compliance with UCAR computer security requirements? A: On Windows, the software we use automatically shuts down all other connectivity to the system when the VPN is up, so you don't need to do anything. On Linux, you need to either turn off all services that are not allowed under our security requirements, or use ipchains to block access from external networks to services you are running that are not allowed. We can provide ipchains scripts that will automatically turn on access blocks when your VPN comes up and turn them off when it comes down. You need to be sure that IP Firewalling is enabled in your kernel. To see the nitty gritty details of our security requirements, go to http://www.ucar.edu/csac and click on "Security Standards for Exposed Hosts". The relevant documents are the "External Network Connectivity Policy" and the "Network Services Standards". Q: Is there any way to network with machines on my local net at the same time that I have a VPN connection to UCAR? A. For Windows, the answer is no. There is no way to do this safely. For Linux, the answer is a qualified "yes" but it requires some knowledge of the Linux kernel's firewall system (ipchains) in order to be able to keep local connections open while still meeting our security requirements. (The answer for *BSD would be similar to that for Linux). Ensure that your system is in compliance with the CSAC security standards for fully exposed hosts. Unlike the Windows client, while the Freeswan VPN is up, connectivity to the rest of the network is still open, therefore you must take steps to ensure that your system is not a back door around our security perimeter. Note that this also means that you must agree to permit the UCAR Security Administrator to scan your host to verify compliance, as with any other exposed host on UCAR's network. I can probably help you write some ipchains firewall rules to accomplish this, and it is possible to impose restrictions on access to your machine only while the VPN is up (although of course for you own protection you should be taking security precautions anyway; unsecured Linux systems are a fairly easy target for hackers). To see what kinds of restrictions are involved here, go to http://www.ucar.edu/csac and click on "Security Standards for Exposed Hosts".

Other Wireless info: Addresses the WEP insecurity issue Right now we’re not requiring it (but CSAC may in the future) I’ll talk about the WEP insecurity issue more in my wireless talk

VPN performance impacts Wired ~4.5% TCP “performance hit” ~8.5% UDP Wireless ~7-8% TCP (I got ~25% with Cisco IPSec client) ~20-25% UDP (I got ~8% with Cisco IPSec client) My informal tests are available from links off the NETS VPN project web page

Other VPN issues Check applications using local IP address (e.g., PC X-Window programs) Must set application to use the IPSec “client IP address” from VPN client software NAT issues Windows client will masquerade UDP connections Linux—NAT device must forward IPSec packets (or have a Linux box do IP masquerading for other hosts behind it also run FreeS/WAN)

Miscellaneous What didn’t work (or what we decided not to use) Certificates We could import our existing private CA and IPSec sub-CA certificates Unsuccessful in making it accept an identity certificate. (couldn’t find correct format to use) PGP client with certificates would have solved Macintosh and W2K; used W2K beta client instead PPTP Left client machine too insecure

Miscellaneous “LAN-to-LAN” connections For Linux users with FreeS/WAN Made them work, but too much overhead (separate manual configuration information entry for each user) No present Mac and Solaris solution Solved with new Cisco IPSec client in 3/2001? No OSPF routing advertisements for VPN client IP addresses Not available in current version Set static route for this group of IP addresses

Miscellaneous What worked (or “we took the easy way out”) Windows client solved Windows access (W2K beta testing program involvement) FreeS/WAN solved Linux access (required separate server purchase) Solving the problem for Windows and Linux users covered most of our user base

Conclusion Details and more information on NETS “Projects page” http://www.scd.ucar.edu/nets/projects/vpn Questions?