What We’re Reading, Week of 1/25

The Windows Blog…
Remote Access Challenges
In this post, Alexander Kent explains some of the most common remote access challenges and offers advice on how to make your Windows Home Server accessible across the Internet. He addresses these issues: UPnP is not enabled or supported by your router, an Internet Service Provider is blocking Remote Access Ports, and Double NAT. If you have experienced issues with any of those challenges, this breakdown should be helpful.

Insecure about Security…
Will 2010 Be “The Year of IPv6?”
John Oltisk believes that the foundation of IPv6 is now firmly in place and we will see steady and growing momentum in the years to come and that by 2013, the transition will be nearly completed. He makes this prediction for the following reasons: the argument that we are running out of IP addresses is now taking hold, IPv6 is now supported in all major operating systems including Windows, Linux, MacOS, and z/OS, many governments around the world already run on IPv6 or are in the process of transitioning to IPv6 and IPv6 security will become more and more important moving forward.

Securosis…
Security Strategies for Long-Term, Targeted Threats
This post offers some security strategies for dealing with long-term, targeted threats such as the Advanced Persistent threat in Firestarter. One suggestion is to segregate networks and information since the more internal barriers an attacker needs to traverse, the greater your chance to detect. However, allowing VPN access across these barriers won’t help segregation nearly as much. The root cause of many breaches has been a weak endpoint connecting over VPN to a secured network. You can use NCP’s Secure Entry Client to make sure this does not happen.

What We’re Reading, Week of 1/18

Insecure about Security…
Approximately Half of All Organizations Will Increase Security and Networking Spending in 2010
In this post, John Olstik says that nearly half of all mid-market (100 to 999 employees) and enterprise (1,000 employees or more) companies will increase their spending on network hardware in 2010. Their top priorities will include WLAN, IP telephony, and WAN optimization. 48 percent of mid-market organization will increase their spending on information security technologies while 61 percent of enterprises will increase their spending on information technologies. Their top priorities are network security, endpoint security, and messaging/web security. John says 2010 will be “a good year for vendors to re-engage with customers, build long-term partnerships, and help them move beyond the Status Quo.”

IT Business Edge…
Evaluate Technologies with Remote Access in Mind
This post by Paul Mah discusses the new research from collaboration firm oneDrum, showing that many workers find themselves unable to work from home despite the fact that they are willing to do so. According to the survey, 61 percent of employees never work from home, even though 72 percent of SMBs allow it. One main reason for this was that work documents were not accessible outside of the office. Paul suggests that businesses gradually move toward teleworking, which can be achieved by evaluating new technologies with an eye toward facilitating it. Also, see our series of posts on how to rethink remote access.

The Security Catalyst…
Security from Scratch: Getting the Lay of the Land
Dennis Kurtz says that when building Security from Scratch, the challenge is in understanding the situation from the start. Once the team is identified/assembled, the focus shifts rapidly to getting a handle on the security posture of the organization. These are the areas Dennis considers his tactical review to understand what challenges lie ahead and to form a plan of action: Information Security Policy, Network/Perimeter Security Posture, SDLC Security Policies/Procedures/Practices and Applicable Compliance Requirements, Security Awareness. When checking for Network/Perimeter Security Posture,  Dennis recommends finding out if  remote access allowed and if so, how – VPN, SSH, nothing?

Arcane IP Conflict to Watch Out For

Every once in a while, someone flags the NCP Help Desk with an arcane VPN connection question. Earlier this week, we came across a blog post by Merrick Chaffer on EMC Consulting Blogs, offering advice on just such an issue, and we thought we’d share it. Merrick decided to solve the problem on his own (Help Desk certainly would have ‘cracked this nut’ in an hour or so!).  

After spending a couple of weeks worrying that I’d have to be plugged directly into my router to connect to my work VPN network, with my Dell D830 Latitude laptop and Windows 7 64 bit, I finally chanced upon the solution. It turned out to be a device manager setting and potentially a setting in the BIOS on my D830 dell latitude (bios revision A14).

Follow the following steps if you are suffering the same issue yourself…

1. Changed the MTU setting on the VPN device…

2. Changed a setting in the bios, which dictated that the wifi connection should be turned off when another connection is available (i.e. LAN or 3G).

UPDATE: 23:15 15 January 2010: Actually I’ve just discovered the real route of my problems. Turns out that if my router (3com office connect adsl wireless 11g firewall router), assigns an ip address that is in use by one of the virtual server LAN IP addresses, on either wireless connection or LAN connection, then the VPN software fails to connect.

What actually happened was when I plugged another router into my firewall router, I got assigned 192.168.1.3 to my laptop wireless card, which wasn’t one of the entries in the virtual servers table, and that’s when it started working.

So if you have trouble connecting, double-check if you have conflicting IP addresses, or, drop us a line – help@ncp-e.com or @VPNHaus

What We’re Reading, Week of 1/11

Securosis…
Low Hanging Fruit: Network Security
In this post, Mike Rothman offers some tactics that anyone can use to ensure their existing equipment is optimized. He will be highlighting network and endpoint security, as well as security management in his next post. He starts with the network and offers these suggestions: prune your firewall, consolidate and segregate where possible, hack yourself, revisit change control and filter outbound traffic.  Be sure to check out Mike’s next round of tips.

Computer Business Review…
Businesses Ignoring Remote Worker Threat
This article by Steve Evans discusses new research from Check Point that found just 27% of businesses are using encryption to protect their data, despite the number of remote workers increasing. It also showed that 40% of businesses now have more remote workers connecting to the corporate network from home or when traveling than they did during 2008. 49 percent of the companies surveyed have a VPN client in place. We hope that those companies who are not currently connecting to their networks with a secure VPN will start using one.

eWeek…
How to Strategically Secure IT Remote Support
This contributed article by Nathan McNeill says that without a strategic vision for remote control security, organizations will continue to fall prey to hackers taking advantage of IT support departments’ use of remote access tools. He outlines 5 ways to maintain security and corporate governance policies while relying on remote access technology to support off-site computing devices. He recommends developing a remote control strategy, deploying an on-site solution and reviewing third-party validations, ensuring audit-ability and to tier access privileges.

Split Tunneling

Confused about split tunneling—What is it?  Is it secure?  Is it recommended?  We spoke with Rene Poot, senior solutions specialist at NCP engineering for his opinions on this.

Lets first define split tunneling—

Let’s take a typical Windows machine, and place it in a home office environment.  In this home office environment, the user also accesses resources on his/her home network, such as a network storage device or another machine in his local network.  There will be a router present that performs firewall functions and network address translation, and provides Internet connectivity for all the machines within this home network.

When the user wants to access something on his local network, by default the Windows IP stack will look to find the shortest route to this resource.  As it is something local, it will send it to the local network interface and send the request to its local LAN.  If it is a destination that is unknown, it is sent to the so-called default gateway, which would typically be this home network’s router, which then hides the internal IP address of this machine, and routes the request out to the Internet, as though it’s coming from the router/firewall.  The responses then come back to this router who in turn then translates it back and sends it back to this Windows machine.

Now let’s introduce VPN into the picture—

Typically the user wants to connect to his corporate office in a secure manner, and so has VPN.  With ‘Split Tunneling‘ enabled, the user can sit at his machine at home, and all traffic destined for the secured corporate network is directed via the tunnel.  All other traffic is either split off to the local default gateway, or to the local resources directly.  Basically it’s just a ‘junction’ or an ‘access list’ where what needs to be directed.  This can either, depending on the VPN gateway used, be pushed to the client, or the user can define this manually on the client.

Requests for let’s say a public Internet website expedia.com is then examined, and compared to the ‘split tunneling’ list.  This is a list of all the hosts and/or subnets that are to be diverted through the tunnel.  Destinations not on this list will be directed to the default gateway.  In this example, it’s unlikely that expedia.com is on this list, and so is sent to the default gateway (the router/firewall at home and out on to the Internet).

If however, the user wants to access a resource on the corporate network, they will do so, and the destination will match a destination that’s listed in the Split Tunneling ‘list’, and so it’s directed through the tunnel, and will emerge on the VPN gateway and then on to the corporate network.

Traffic for the local shared resource will simply go directly to that device on the local network and everything’s fine.

Now, it could be the case that the administrator does NOT want this to be so ‘open’.

At the corporate side, they’ve installed a firewall and locked and bolted everything down, out of fear or any accidental data leakage (i.e. via IM or access to popular websites, or whatever).  Users on the corporate network are not permitted to be looking at holiday booking sites such as expedia.com and so this is blocked by the firewall.  One is permitted only to use the company resources for corporate use and in corporate situations.  Browsing other websites are not permitted, because the user cannot be trusted he/she won’t access some nefarious website or whatever.

Now if this user is permitted to take this laptop home, and no other steps are taken, all bets are off.  The firewall rules and such that the administrator so carefully has set up to protect his corporate network no longer apply, because the machine is now at the mercy of the firewall settings of the local router/firewall at home, which will not reflect the same precautions the administrator has put into the corporate firewall.  One could then access the Internet and do whatever one pleases.

The administrator can prevent this by ensuring the a VPN is required, and ‘lock the user into the tunnel’, which is ‘split tunneling’ but then with a wildcard for all, which effectively makes ALL traffic that emerges from this machine be directed through the tunnel, effectively making the VPN gateway at the corporate side the default gateway of this machine at home.  The corporate firewall then is still protecting this remote resource at home.

One can still access local resources (unless this too is blocked — an additional option within the client software) but any requests to the aforementioned expedia.com will be directed through the VPN tunnel, and then the VPN gateway will forward it to its default gateway, and that then is the corporate firewall, which then drops this request.  This allows the administrator to leverage the control he has over the machine’s access at all time; basically extending the corporate policies to the machine regardless of where it is.

I mentioned that local resources (i.e. shared resources or network printers) are still accessible; this is the case by default, but this too can be locked out; so even that must pass through the VPN tunnel first.

“Locking the user into the tunnel” or “full network enclosure mode” will put more strain on the bandwidth at the corporate side, as EVERYTHING from ALL the remote users that are locked into the tunnel must pass through the central VPN gateway and then the central corporate firewall; so that could have a performance impact.

Follow this conversation @VPNHaus