In late 2006, DarkReading published the 10 most overlooked aspects of security, which I think will end up holding true for a very long time.
I decided to screw around some more and actually recorded the creation of my OpenVPN server. I did this mostly to do something I’ve never done before: make a video of something and cut it.
I used VNC on a Windows box to connect to my Ubuntu 7.04 server. I then recorded that window using CamTasia Studio 3.1, which I also used to add music, edit, and produce. The music is Baja by Sasha. The codec (CinePak codec by Radius) is the only codec available by default in CamTasia that worked on both my Windows box using VLC and Windows Media Player, and also on my Ubuntu laptop using Mplayer. If it doesn’t work for you, I suggest those players, or tough luck. Maybe I’ll choose something better and smaller next time, but for now, this was just a learning experience for me.
The video is over 190MB and runs 12:35. I don’t have a real hoster, so I’ll leave this video up for a few weeks (or hours if it brings me to a crawl!). If it is not available and you want it, email me and we’ll figure something out.
Suggestions are very welcome, but be aware I know this was a very amateur deal. 🙂
I recently stood up an OpenVPN server at home. I’ve done SSH forwarding to protect my hotspot browsing habits in the past, but I thought I would try something new. I installed this on an Ubuntu 7.04 system that was running as a VMWare guest OS. I opted to go with a routed VPN solution. The alternative is a tunneled connection which makes it seem like my VPN client system is right on my home network. My routed solution will rely on the Ubuntu server and my home Linksys router to route traffic from my VPN network (10.8.1.0/24) to my home network (192.168.10.0/24). I also make sure that I force my traffic through my VPN, rather than let it seep out in the clear at the hotspot (the push commands in the server.conf file later on). From bare start to finish, this entire setup can be done in under 15 minutes.
I am not going to detail what each command does except in passing, because there is excellent documentation already available for OpenVPN. What I rarely see, however, is a quick walkthrough on how to set it all up on Ubuntu.
I start out by installing the packages that I need. OpenSSL may not be needed, but I included it anyway.
apt-get install openvpn openssl bridge-utils dnsmasq
Server.conf is the server configuration file. The contents describe that I will run my server on the IP 192.168.10.108 and port 1194 udp. My VPN “network” will be in the 10.8.1.0 255.255.255.0 network. OpenVPN will grab 10.8.1.1 as the server, and my client will be given a similar address. Once my client is connected to my OpenVPN server, I should be able to ping 10.8.1.1 and verify I can talk to my server.
server 10.8.1.0 255.255.255.0
push “route 192.168.10.0 255.255.255.0”
push “redirect-gateway def1”
push “dhcp-option DNS 10.8.1.1”
keepalive 10 120
The client-addresses.txt file is just a convenient way for me to track who gets what IP.
Next I take care of the keys I need, along with some other setup. When creating the keys, I don’t assign a password, and I do select yes to sign and commit changes.
#change values at the bottom and save
cp ca.key ca.crt dh1024.pem server.key server.crt /etc/openvpn/keys
cp client1.crt client1.key ca.crt /etc/openvpn/configs
The file client1.conf is the client config file that needs to be given to the connecting client box. LVVPN is the name of my network adapter on the client. After installing the OpenVPN client on the Windows client, create a new TAP and give it this name.
remote www.terminal23.net 1194
I need to get the client files to the client. I do this by copying them to the client’s home directory, then connecting via SSH to get them. Since I’m running all of this as root, I need to adjust the client1.key file so the client can grab it via SSH, otherwise I’ll get a permission error. I then start the service.
openvpn –genkey –secret ta.key
cp client1.crt client1.key client1.conf ca.crt /home/michael
chmod 604 /home/michael/client1.key
#copy files via SSH to client into openvpn/configs folder
openvpn /etc/openvpn/server.conf &
I’m never satisfied with just doing something, I usually need to verify it. I do this by making sure the service is running and that it is listening on the expected port.
netstat -a | grep 1194
ps -ax | grep vpn
Finally, I need two more commands to enable IP forwarding for my particular setup.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE
Since my home Linksys router is limited to a GUI, it is a bit hard to detail what I did to set up my route. I just added a new route in the Advanced Routing section. Destination LAN IP is 10.8.1.0, subnet mask 255.255.255.0, and default gateway 192.168.10.108. This was set up to let me talk to my internal systems. I also had to port forward my VPN port to this system. This means that after I’m connected, I can ping 10.8.1.1 to verify I am on my VPNs network. I can then ping 192.168.10.1 (or a valid, responsive host on my home network) and I should get a response if forwarding is working.
From here, start up the client’s VPN however you like. Many people start it up by right-clicking the client1.ovpn file (rename client1.conf to client1.ovpn) and choosing to start it as an openvpn connection. I like the tool OpenVPN GUI for Windows. This is merely a personal preference since I like the sys tray interface.
One last thought has been tickling my mind when it came to that WSJ article I linked to the other day. It was about control and telling people not to cross the lines or do things they’re not supposed to do. Think about that for a moment. How far would we get if everyone stayed between the lines? While there are some ethical near-absolutes like murder, most everything else is such small beans that pushing the boundaries now and then can be a good thing. Like working out, you can’t build muscle without first making thousands of micro-tears to induce stronger rebuilding. Growing pains, which are going to be abundant in our culture and technology for some time. Even if we don’t act on them, it is good to think about them and question our policilial (yes, I make up words) stances.
Besides, even if our users know all this junk, we protect against it, right? Full disclosure?
What better time to release a blog-inspiring IT security article in the Wall Street Journal than when half the crowd is in Vegas for the week? Yes, the WSJ posted 10 Things Your IT Department Won’t Tell You, which really should be reworded, 10 Ways to Circumvent Your IT Department’s Restrictions. Here are some notes of mine on the article as a whole.
A. The author needs to stress further that employees should look at their corporate policies and talk to their IT staff. Sometimes it just takes user interest to get management to look at legit technological solutions to the below problems, not workers sneaking around. I wonder if the WSJ wouldn’t mind if its editors sent all their email to a third party service or stored their files online? It would just be nice if the author had constantly (or at least at the beginning) reminded readers that while this is all in good fun, they can be crossing policy lines.
B. The author implies, or rather nearly flat-out states, that these items are part of a rather strict and unfriendly IT security stance. This is really not so. Some things like blocking certain websites are done almost as much for saving bandwidth costs as anything, or to prevent such things as porn viewing which can create a hostile work environment. Other things like email size requirements can be an external limitation by the Internet infrastructure at large (i.e. your target’s mail servers). Likewise, storage is cheap, but try telling that to senior management when the Exchange servers start complaining and buckling and backups take too long. Alleviating that means spending money. And often management figures that money is better saved and file sizes remain reasonable. IT security is not the only force here, but rather simple economics in the IT world. Really, often it comes down to treating everyone equally and costs.
C. Contrary to what every non-IT person seems to think, IT pros do not know everything or every piece of software. Limitations are often made so that we have a finite job description. Supporting every piece of software that even 50 users can install is frustrating and a drain on company money.
D. I don’t like the feeling that the author’s Risks sections are skewed to the POV of the user, and not the business as a whole and how dangerous some of these practices may be. Some are properly framed while others are not.
E. That all said, I think this is an important article. It illustrates the common pains our users (and we as well!!) have when it comes to the convergence of work, culture, technology, and social lives. Each of these pain points should be fixed by IT, or at least the policy behind them transparent to the constituents. Each of these should also be examined to see if, instead of benefiting the company and our employees as people, we’re holding them back and trying in vain to stem the tides of culture and progress.
1. HOW TO SEND GIANT FILES – How many companies really do need to send giant files and don’t have any sort of FTP/SFTP infrastructure? No, your baby pictures in bitmap format and 10 times as big as modern monitor resolutions do not count as a business case. I am saddened to see the author tell users to look for the IE lock symbol as reassurance of validity, and that a Verisign logo further ensures the identity of the site. No, that’s not enough, sorry. Oh, and if an Adobe exec runs it, it is less likely to have security holes. Say what? Anyway, IT does need a plan for transferring large files anyway, so get one. Everyone, and I mean everyone, hits the attachment max at some point. Hell, even Gmail has a max; live with it.
2. HOW TO USE SOFTWARE THAT YOUR COMPANY WON’T LET YOU DOWNLOAD – This one really peeves me, because I’ve too often seen a) malware enter because someone wanted certain software, b) computers become unusable due to crappy software or incompatibilities with business software, and c) frustrated users who then frustrate IT because they MUST have some backwater POS software installed or they will quit, or something equally outlandish. The bane of all IT is having to support everyone’s crap. Yes, I’m jaded on this point, but there is usually a process of requesting and approving software for use in the business. Good IT will log all executed software, and query on why they were run. And be aware of your company size. Small companies can likely get more software approved, but large or medium companies just cannot scale IT to support every little thing.
3. HOW TO VISIT THE WEB SITES YOUR COMPANY BLOCKS – First, web-based email is not innocuous. Second, if your company blocks these sites actively, your proxy calls will likely be logged as well. If you need a site opened up or something, ask your manager, HR, or IT. If it is Final Four season and you can’t stream the first round games, well, sorry, but we can’t bring the internet access to a crawl just to see a 15 seed get crushed by a 2 seed in a game that will be played regardless if you are watching or not. And no, you can’t connect to GoToMyPC.
4. HOW TO CLEAR YOUR TRACKS ON YOUR WORK LAPTOP – I really like the author saying, “…don’t use your work computer to do anything you wouldn’t want your boss to know about.” That’s it in a nutshell right there; that should be everyone’s personal policy.
5. HOW TO SEARCH FOR YOUR WORK DOCUMENTS FROM HOME – Ugh. Don’t ask your IT admin to help you set up Google Desktop. Bad. Ask how you can get set up with a VPN connection from home that is secure and allows you access to your computer or a file store. The author stupidly says three things that he/she should have put together. “…top-secret financial information…” and “…search company keeps a copy of your documents on its own server…” and “…myriad state laws regulate how a company has to react when it loses private information…” If you play the “duh” game, you see that you might have to provide some answers why you are allowing top secret, possibly regulated, information to be stored on third-party servers. Good job.
6. HOW TO STORE WORK FILES ONLINE – Like web-based email services, thinking too much about this problem creates ulcers. Yes, I’d like to encourage my users to store their files on third party services, because then they can store megs and gigs of company data out there, then quit (or god forbid get fired), and leave the company with absolutely no means to recover, inventory, or secure that data. Brilliant. These services should be stopped via web filters and software install restrictions, let alone via policy. Oh, and kudos to the author to recommend USB and other portable devices in item #2, then calling them cumbersome in this one.
7. HOW TO KEEP YOUR PRIVACY WHEN USING WEB EMAIL – These “nifty tricks” can spell doom for compliance, if that is your company’s game. Tracking this stuff is such a grey area it’s sick. Honestly, I don’t like my stuff logged for perusal by my manager or HR; I really am part of the generation whose social lives tend to revolve around electronic means. But I do prefer to have things logged just in case, from both my personal POV and from the company POV. We need to make sure our processes and actions are transparent so that employees don’t think we’re reading their IM/email logs to get juicy gossip details. Chances are not good for that happening, sadly.
8. HOW TO ACCESS YOUR WORK EMAIL REMOTELY WHEN YOUR COMPANY WON’T SPRING FOR A BLACKBERRY – Another ulcer about data free-flowing out the company door, but at least the author implores readers to talk to IT.
9. HOW TO ACCESS YOUR PERSONAL EMAIL ON YOUR BLACKBERRY – I don’t see a huge problem with this, until you a) run that attachment…oops, that was a virus and screw things u, b) can’t get it to work and ask IT in which case we’ll tell you no and watch you closer, or c) email that really important client from…oops, your personal email hotjerkyboy69foru from hotmail. Explain that to your boss…
The last one is just a light-hearted gimme; a lame contrivance of journalistic levity.
In the end, all of this comes down to a few protections by IT that can make a lot of these issues be blocked properly:
i. software restrictions based on policy and technology, including executable logging
ii. web filtering, or at least logging if not outright blocking
iii. data privacy/sensitivity training and strict adherence to least privilege access rights, better yet, full logging of all data downloaded/viewed, but good luck with that
iv. work with your users to overcome these challenges and find a happy middle ground