If your company has people on the road, such as sales or technical people, a VPN is a good method for letting them access data on the company network. Many different VPN solutions can be bought, but many are free. Here, I discuss only solutions you can set up without buying a commercial VPN product.
The main VPN solution used for more complex tasks is IPsec; some people use PPTP. Although PPTP is usable, security flaws have occurred in its past, and it simply does not match up to IPsec.
IPsec in tunnel mode would be a much better solution, were it not for the crippled Windows-client implementation: Windows XP/2000 clients can't use IPsec in tunnel mode without using L2TP. There is nothing wrong with L2TP security-wise, but it increases latency--through the need for both PPP and L2TP processes--and increases packet-overhead, slowing down connections. Open-source servers have not had much experience with L2TP yet, so using open source for it is problematic at this time.
A disadvantage of plain IPsec is its notorious complexity: many, many things can and do go wrong. To the rescue, then, comes OpenVPN, a full-blown open-source VPN solution based on SSL. OpenVPN offers the same functionality as IPsec in tunnel mode; you can tunnel entire networks through it. In this article, I focus on using OpenVPN as a road warrior's VPN solution.
Every VPN approach has its list of pros and cons. The pros of OpenVPN are:
Same functionality as IPsec in tunnel mode: you can tunnel entire networks (IP tunnel or bridging tunnel).
A Windows XP/2000 install.exe file with a GUI is available for starting the tunnel. The config files are text based.
The OpenVPN server can push routes, DNS server IP addresses and other configuration details to the clients. This makes OpenVPN well suited for road-warrior setups, because you can modify the setup without touching far-away laptops.
You can use a bridging or routing setup.
The server/client code is the same: the config determines the role.
SSL is as solidly proven as security protocols get, using RSA public key cryptography if you want. See this paper for more information on its security setup.
OpenVPN costs you nothing in terms of money--a server, an Internet connection and know-how is all you need).
All encryption processes are handled in userland, meaning it is easy to install--much less complicated than IPsec.
The list of cons includes:
The setup uses TUN/TAP devices. This can make things complicated to figure out when things go wrong. If Microsoft changes its code, it also might just break.
The OpenVPN process is executed in userland and, thus, is relatively slow. TUN/TAP devices combine together with a userland-process to create a setup in which traffic has to cross userland/kernel borders relatively often. This setup might create rather high latency on connections.
A packet overhead is present because IP/Ethernet is encapsulated in SSL and SSL in UDP/TCP.
The latest version OpenVPN is beta; earlier versions have further drawbacks.
Who can you call when things go wrong? Some companies want to pay to get support.
Considering these arguments, OpenVPN should be a serious option if you are setting up a VPN. The days when only money could get you a decent VPN definitely are over.
The rest of this article is a guide to setting up a road-warrior scenario using routing, not bridging, with TUN devices. Its aim is to make sure laptops on the Internet can connect safely to companies' networks, using internal servers and data.
The basic HOWTO I drew on when writing this article can be found here. It is a HOWTO for setting up OpenVPN in bridging mode on a Linux SME-server. My setup is slightly different, because I do not use a bridging setup. Another good source is the OpenVPN HOWTO.
The Security Setup
Anyone setting up a VPN without considering the different kinds of security risks one faces is a fool. Therefore, you should start any VPN setup doing exactly that--considering security.
OpenVPN traffic flowing over the Internet is protected by TLS. The setup here uses public key exchange; computer authentication is done by RSA-based public/private key-pairs (public keys also are called certificates). In this setup we make our own root certificate; that is, for our VPN scheme, we are our own Verisign, so to speak. We are the root of the Web of trust here. We make a server key pair and multiple client-key pairs. We sign those with our own root certificate. This setup is this basic cryptography design of OpenVPN.
The SSL/TLS connection is set up up with those keys. After authentication is done, Diffie-Hellmann encryption is used to exchange keys to set up the connection. New keys are negotiated every hour using perfect forward secrecy, or PFS--the next key used is not derived by using the former key. By default, the connection uses 128-bit Blowfish in Cipher Block Chaining mode, with SHA1 message digests.
The OpenVPN server itself, of course, could be attacked. You can minimize that risk by:
Using shared keys with the tls-auth option before public key exchange occurs. Doing so keeps people from exploiting the SSL setup, should this be possible.
Setting options user nobody and group nobody. This makes sure the server does not run as root. You also can use a chroot-jail.
Using a separate box in a DMZ. This way a successful hack is slowed down by the firewall protecting the internal network from the DMZ. Strange connects can be noticed in the firewall logging.
By using iptables firewall rules on the OpenVPN server that prevent traffic from tunnel hosts entering the server, as well as all traffic from the Internet except for the need UDP traffic.
Authentication of Users
The security setup of your client laptops is critical. If your road warriors are using laptops and can access your company's network, your data may become public in the future. No matter how good the SSL crypto, this is a separate risk. If a laptop can connect through an OpenVPN tunnel directly into your networks, you have a problem. To avoid this, you need to establish authentication of the user to the laptop or to the SSL keys.
Many ways exist to do this authentication. You can password-protect the SSL keys of the client, which is recommended. But if workers have the habit of writing down passwords near their laptops, password protection is not sufficient. An option is to get USB-based iKeys with a pincode that holds the client keys. Pincodes are easier to remember, so the need to write them down is smaller. Of course, the iKey should be carried on a keychain and not with the laptop itself. You should establish an AUP (acceptable user policy) to make sure all users understand this. Doing so may prevent a stolen laptop from becoming a disaster. In addition, you might use encrypted filesystems on laptops.
Another option is to set up your own custom authentication scheme. For instance, you can use strong authentication with hardware tokens, coupled with a Kerberos server. OpenVPN has the script hooks to do that. You also can use the server password file.
The network setup my configuration files is aiming for is this:
The OpenVPN server at 65.66.45.x.
The client is somewhere on the Internet.
The client/server P2P network is 192.168.100.0/24 or, rather, a /32 network in that network.
The company-network behind the OpenVPN server is 172.16.1.0/24.
So, the internal mailserver of this company might be at 172.16.1.3, the DC at 172.16.1.5 and the fileserver at 172.16.1.6. Schematically, this setup looks like this:
CLIENT -> [modem/adsl-router] -> Internet <-UDP-> OpenVPNserver CLIENT - TUNInterFace <=tunnel=> TUNInterFace ==> Internal network CLIENT - 192.168.100.6 <=======> 192.168.100.5 <==> 172.16.1.0
I am using a Linux SME-server, which basically is a Red Hat system stripped down to what a file/printer/firewall/e-mail server needs, with a Perl/HTTP-based config panel. After being a problematic open-source project for a while, Linux SME-server is being developed further by Lycoris. I have used Linux SME-server for years and will migrate only if forced to--it is extremely easy to use.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide